📰 Informação fresquinha chegando para você!
Sua opinião é importante: leia e participe!
Apoie esse projeto de divulgacao de noticias! Clique aqui
Uma falha no Google Cloud Vertex AI SDK para Python permitiu que um invasor sem acesso ao projeto da vítima sequestrasse o modelo de aprendizado de máquina da vítima, carregasse e executasse código dentro da infraestrutura de serviço do Google.
A Unidade 42 da Palo Alto Networks, que encontrou e relatou o bug por meio do programa de recompensas de bugs do Google, chama a técnica de “Pickle in the Middle” e disse que não viu nenhuma exploração na natureza. O Google corrigiu isso; se você usar o SDK, atualize para a versão 1.148.0 ou posterior.
O invasor precisava apenas de um projeto próprio do Google Cloud e do ID do projeto da vítima, que geralmente é público. Nenhuma credencial, nenhum phishing, nenhuma posição no alvo.
A falha estava em como o SDK escolheu um intervalo temporário do Cloud Storage para uploads de modelos. Se um usuário não definisse um bucket, o SDK geraria um nome previsível a partir do ID e da região do projeto, como project-vertex-staging-region. Ele verificou se aquele balde existia, mas não se a vítima o possuía.
Como os nomes dos buckets são globalmente exclusivos, um invasor pode criar primeiro o bucket esperado em seu próprio projeto. O SDK da vítima carregaria então os arquivos do modelo para o bucket do invasor. O invasor poderia então substituir o modelo carregado por um malicioso.
Muitos modelos Python ML são salvos com pickle ou joblib, que podem executar código quando um arquivo é carregado. Quando a Vertex AI carregou posteriormente o modelo trocado, o código do invasor foi executado dentro do contêiner de serviço.
O ataque dependia da velocidade. A unidade 42 mediu cerca de 2,5 segundos entre o upload da vítima e a leitura do arquivo pela Vertex AI. Em sua prova de conceito, o invasor usou uma Cloud Function que foi acionada após o upload e substituiu o modelo em 1,4 segundos, antes que a Vertex AI o lesse.
A carga então roubou um token OAuth do servidor de metadados do contêiner de serviço e o enviou ao invasor. No ambiente de teste da Unidade 42, esse token não se limitou à implantação comprometida. Ele poderia acessar outros artefatos de modelo no mesmo projeto de locatário gerenciado pelo Google, incluindo um modelo completo do TensorFlow com pesos treinados, bem como metadados do BigQuery, listas de acesso, registros de locatários, nomes de cluster do GKE e caminhos de imagens de contêineres internos.
O ataque funcionou apenas sob condições específicas: o intervalo de teste padrão da vítima ainda não existia naquela região e a vítima deixou o parâmetro staging_bucket não definido. O primeiro é comum para um novo projeto na Vertex AI em uma região.
A segunda depende de o desenvolvedor confiar no padrão do SDK em vez de nomear seu próprio bucket.
A Unidade 42 relatou a falha por meio do Programa de Recompensa de Vulnerabilidade do Google em 5 de março de 2026. Ela testou as versões 1.139.0 e 1.140.0, as mais recentes disponíveis na época, e encontrou ambas vulneráveis.
O Google enviou uma correção inicial na v1.144.0 em 31 de março, adicionando um uuid4 aleatório ao nome do intervalo. A correção foi concluída na v1.148.0 em 15 de abril, adicionando a verificação de propriedade do bucket para bloquear a ocupação de buckets em Model.upload(). Até a publicação, nem a Unidade 42 nem os boletins de segurança Vertex AI do Google listam um CVE para o problema.
Atualize para 1.148.0 ou posterior para que a verificação de propriedade fique ativa. Além disso, defina um staging_bucket explícito para um local do Cloud Storage que você controla ao fazer upload de modelos. Como a lógica defeituosa reside no SDK do cliente, verifique a versão google-cloud-aiplatform onde quer que ela seja executada, incluindo notebooks, trabalhos de CI e pipelines de treinamento, não apenas serviços de produção.
É a segunda falha com nome de intervalo previsível a surgir na Vertex AI este ano. O Google corrigiu o CVE-2026-2473 em fevereiro, um bug separado nos experimentos Vertex AI que também permitia a execução de código entre locatários, roubo de modelo e envenenamento.
O trabalho anterior da Unidade 42 sobre as permissões padrão do agente de serviço da Vertex AI rastreou um caminho relacionado de um agente de IA implantado até os dados do cliente e do locatário.
A Unidade 42 da Palo Alto Networks, que encontrou e relatou o bug por meio do programa de recompensas de bugs do Google, chama a técnica de “Pickle in the Middle” e disse que não viu nenhuma exploração na natureza. O Google corrigiu isso; se você usar o SDK, atualize para a versão 1.148.0 ou posterior.
O invasor precisava apenas de um projeto próprio do Google Cloud e do ID do projeto da vítima, que geralmente é público. Nenhuma credencial, nenhum phishing, nenhuma posição no alvo.
A falha estava em como o SDK escolheu um intervalo temporário do Cloud Storage para uploads de modelos. Se um usuário não definisse um bucket, o SDK geraria um nome previsível a partir do ID e da região do projeto, como project-vertex-staging-region. Ele verificou se aquele balde existia, mas não se a vítima o possuía.
Como os nomes dos buckets são globalmente exclusivos, um invasor pode criar primeiro o bucket esperado em seu próprio projeto. O SDK da vítima carregaria então os arquivos do modelo para o bucket do invasor. O invasor poderia então substituir o modelo carregado por um malicioso.
Muitos modelos Python ML são salvos com pickle ou joblib, que podem executar código quando um arquivo é carregado. Quando a Vertex AI carregou posteriormente o modelo trocado, o código do invasor foi executado dentro do contêiner de serviço.
O ataque dependia da velocidade. A unidade 42 mediu cerca de 2,5 segundos entre o upload da vítima e a leitura do arquivo pela Vertex AI. Em sua prova de conceito, o invasor usou uma Cloud Function que foi acionada após o upload e substituiu o modelo em 1,4 segundos, antes que a Vertex AI o lesse.
A carga então roubou um token OAuth do servidor de metadados do contêiner de serviço e o enviou ao invasor. No ambiente de teste da Unidade 42, esse token não se limitou à implantação comprometida. Ele poderia acessar outros artefatos de modelo no mesmo projeto de locatário gerenciado pelo Google, incluindo um modelo completo do TensorFlow com pesos treinados, bem como metadados do BigQuery, listas de acesso, registros de locatários, nomes de cluster do GKE e caminhos de imagens de contêineres internos.
O ataque funcionou apenas sob condições específicas: o intervalo de teste padrão da vítima ainda não existia naquela região e a vítima deixou o parâmetro staging_bucket não definido. O primeiro é comum para um novo projeto na Vertex AI em uma região.
A segunda depende de o desenvolvedor confiar no padrão do SDK em vez de nomear seu próprio bucket.
A Unidade 42 relatou a falha por meio do Programa de Recompensa de Vulnerabilidade do Google em 5 de março de 2026. Ela testou as versões 1.139.0 e 1.140.0, as mais recentes disponíveis na época, e encontrou ambas vulneráveis.
O Google enviou uma correção inicial na v1.144.0 em 31 de março, adicionando um uuid4 aleatório ao nome do intervalo. A correção foi concluída na v1.148.0 em 15 de abril, adicionando a verificação de propriedade do bucket para bloquear a ocupação de buckets em Model.upload(). Até a publicação, nem a Unidade 42 nem os boletins de segurança Vertex AI do Google listam um CVE para o problema.
Atualize para 1.148.0 ou posterior para que a verificação de propriedade fique ativa. Além disso, defina um staging_bucket explícito para um local do Cloud Storage que você controla ao fazer upload de modelos. Como a lógica defeituosa reside no SDK do cliente, verifique a versão google-cloud-aiplatform onde quer que ela seja executada, incluindo notebooks, trabalhos de CI e pipelines de treinamento, não apenas serviços de produção.
É a segunda falha com nome de intervalo previsível a surgir na Vertex AI este ano. O Google corrigiu o CVE-2026-2473 em fevereiro, um bug separado nos experimentos Vertex AI que também permitia a execução de código entre locatários, roubo de modelo e envenenamento.
O trabalho anterior da Unidade 42 sobre as permissões padrão do agente de serviço da Vertex AI rastreou um caminho relacionado de um agente de IA implantado até os dados do cliente e do locatário.
Fonte: https://thehackernews.com
#samirnews #samir #news #boletimtec #falha #no #sdk #do #google #vertex #ai #permite #que #invasores #sequestrem #uploads #de #modelos #por #meio #de #bucket #squatting
⚡ Fique ligado: novidades e promoções em breve por aqui! ⚡
Postar um comentário