- O Chromium Money Tree Browser mapeia as recompensas do Chrome VRP para o histórico de alterações por diretório e arquivo no repositório do Chromium, permitindo ver onde as recompensas de segurança se acumularam na árvore de código
- O valor da recompensa é distribuído dividindo pelo número de arquivos modificados, então se uma correção de bug com recompensa de $1.000 alterar 5 arquivos, cada arquivo recebe $200
- A agregação no nível superior mostra root $9,873,277 / 10.944 casos, chromium $9,014,838 / 10.218 casos, chrome $2,568,260 / 2.574 casos
- Várias áreas como chrome/browser/ui/views, extensions, media, safe_browsing, enterprise, Android, net, device, gpu, storage, base, iOS, pdf aparecem detalhadas até o nível de arquivo, e o V8 também representa uma fatia grande com $858,439 / 726 casos
- Há um aviso de que os dados e a UI estão em estado “very very hacked together”, e o escopo vai só até o início de novembro de 2023, então faz mais sentido ver isso como um mapa exploratório do que como material contábil exato
Como o valor das recompensas é distribuído na árvore de código
- É um navegador que mostra as recompensas de bug bounty do Chrome VRP ligadas à árvore de arquivos e diretórios do código do Chromium
- Se uma correção de segurança altera vários arquivos, o valor da recompensa é dividido pelo número de arquivos e atribuído a cada um deles
- Essa ligação serve mais para observar “que partes do código costumam mudar junto com recompensas de segurança”
- Só a agregação do topo já mostra uma distribuição relevante de recompensas por todo o Chromium
- root: $9,873,277 / 10.944 casos
- chromium: $9,014,838 / 10.218 casos
- chrome: $2,568,260 / 2.574 casos
- chrome/browser: $2,250,643 / 1.920 casos
Distribuição por diretório que mais chama atenção
- Em chrome/browser/ui/views, a distribuição de recompensas aparece bem detalhada por funcionalidades da interface do usuário
- views: $514,665 / 441 casos
- tabs: $56,705 / 30 casos
- eye_dropper: $47,000 / 7 casos
- bookmarks: $46,697 / 31 casos
- payments: $43,623 / 60 casos
- media_router: $36,395 / 12 casos
- tab_sharing: $30,591 / 9 casos
- As áreas ligadas a extensões do Chrome também aparecem repetidamente como blocos grandes
- extensions: $157,507 / 262 casos
- extensions/api: $115,471 / 161 casos
- api/tabs: $42,705 / 48 casos
- api/debugger: $28,488 / 35 casos
- api/downloads: $15,225 / 13 casos
- Uma área separada de extensions também soma $132,615 / 213 casos, incluindo renderer, guest_view/web_view e a API de file_system
- O V8 parece ser a maior área isolada nos dados fornecidos
- V8 total: $858,439 / 726 casos
- v8/src: $626,845 / 503 casos
- v8/test: $209,030 / 195 casos
- v8/src/compiler: $151,267 / 85 casos
- v8/src/heap: $91,891 / 64 casos
- v8/src/builtins: $68,133 / 30 casos
- v8/test/mjsunit: $164,644 / 113 casos
- Em chrome/browser, chamam atenção pontos de contato com o usuário como UI, abas, preenchimento automático, senhas, DevTools e menu de contexto do renderizador
- chrome/browser/autofill: $114,656 / 40 casos
- chrome/browser/tabs: $92,316 / 25 casos
- passwords: $51,060 / 10 casos
- chrome_content_browser_client.cc: $51,512 / 11 casos
- devtools: $48,255 / 35 casos
- renderer_context_menu: $47,842 / 16 casos
- printing: $42,225 / 14 casos
- payments: $41,252 / 10 casos
- Áreas de mídia, segurança, enterprise e plataforma também somam valores altos
- media: $134,523 / 65 casos, enquanto a área separada chrome/browser/media soma $89,008 / 34 casos
- safe_browsing: $80,161 / 31 casos
- enterprise: $59,000 / 38 casos
- ash: $130,389 / 161 casos, com outra área ash seguindo com $56,867 / 55 casos
- mojo: $112,725 / 26 casos
- net: $97,558 / 175 casos
- device: $61,770 / 32 casos
- gpu: $51,155 / 30 casos
- storage: $48,303 / 66 casos
- base: $36,013 / 27 casos
- Android e iOS também têm a distribuição separada em código específico de plataforma
- Áreas de Java, recursos e testes em chrome/browser no Android: $94,441 / 159 casos
- Caminho Android Java: $62,571 / 91 casos
- Android fullscreen: $18,707 / 11 casos, com FullscreenHtmlApiHandler.java em $18,540 / 10 casos
- iOS: $33,625 / 86 casos
- ios/chrome/browser/web: $11,663 / 4 casos
- ios/chrome/browser/ui: $9,884 / 24 casos
Arquivos de teste e cuidados na interpretação
- Dados de teste e arquivos de teste de regressão também entram na distribuição das recompensas
- test: $147,193 / 311 casos
- test/data: $116,355 / 271 casos
- test/data/extensions/api_test: $59,337 / 166 casos
- V8 test/mjsunit/regress: $82,180 / 58 casos
- V8 test/mjsunit/compiler: $46,233 / 28 casos
- Isso acontece porque, quando uma correção de segurança é registrada junto com mudanças em arquivos de teste, esses arquivos também recebem parte da recompensa
- Como o método de cálculo é simples, é difícil interpretar o valor diretamente como risco ou causa de vulnerabilidade
- Como a recompensa é dividida pelo “número de arquivos modificados”, o valor atribuído a um arquivo não representa diretamente o risco daquele arquivo em si
- Há um aviso de que os dados e a UI estão em estado “very very hacked together” e de que não se deve esperar boa UX nem dados exatos
- O recorte dos dados vai até o início de novembro de 2023
- Um link de discussão relacionado também é fornecido
1 comentários
Comentários do Hacker News
Bem parecido com algo que eu queria criar há tempos. Achei que seria útil calcular a probabilidade de uma determinada mudança causar problemas com base no histórico de mudanças destrutivas ocorridas no passado no mesmo arquivo ou na mesma área do arquivo
Basicamente, seria atribuir uma pontuação de risco a cada mudança e mostrar essa pontuação em cada PR, para que o revisor saiba em qual código prestar mais atenção, além de destacar mudanças arriscadas também na hora do deploy
A parte difícil é continuar rastreando a mesma área do código quando a posição do código sobe ou desce por causa de inserções/exclusões acima; algoritmos que dependem simplesmente de números de linha têm problemas aqui
Ainda assim, como neste caso, parece que só no nível de arquivo já pode ser útil o bastante
Para mudanças de maior risco, rodamos mais testes — não testes unitários, mas testes de cliente. Às vezes há 100 mil testes de cliente para escolher, então nós os ranqueamos e executamos só um subconjunto pequeno
É um problema difícil. Uma observação interessante é que, dentro da mudança causadora, há um ou dois símbolos causadores, mas a conectividade desses símbolos é muito parecida com a de símbolos não causadores na mesma mudança
Além disso, depois da mudança, o grafo de chamadas modificado transitivamente fica bem grande; profundidade 50 não é raro. Fora o grau de sobreposição entre os símbolos afetados transitivamente entre a mudança e os testes, foi difícil extrair muitos sinais úteis
O nível de arquivo e o nível de alvo de build eram grosseiros demais; símbolos de AST têm funcionado bem
Muito legal. Mas acho que alguns itens ficaram de fora. Tenho certeza de que havia pelo menos um em third_party/ffmpeg
Esse tipo de correção costuma entrar primeiro no upstream, então pode ser difícil de rastrear
Ao olhar para o grande conjunto sob chrome/browser/ui, dá para pensar em quantos use-after-free aparecem em dados nos quais a vantagem de desempenho do gerenciamento manual de memória não importa muito. Por exemplo, [1] é um problema em torno do ciclo de vida da caixa de diálogo “Selecionar arquivo”
No panorama geral, parece melhor usar sempre ponteiros mais inteligentes, ainda que mais lentos, como defesa nesse tipo de código. Em [2], o tipo
raw_ptr[3] parecia tentar ajudar nisso, e talvez o crash de [2] seja, na verdade, um caso em que a defesa funcionouÉ uma pena não haver, dentro do projeto, uma boa maneira de alternar dialetos de forma mais ampla entre “esta parte é código sensível a desempenho e revisado com cuidado” e “esta parte é código pouco sensível a desempenho, com muito estado assíncrono e propensa a erros”. Já pensei que talvez valesse a pena misturar uma linguagem separada com GC para esta última
A propósito, trabalhei nesse código há muito tempo, e não ficaria surpreso se eu tivesse criado mais de zero desses bugs
[1] https://bugs.chromium.org/p/chromium/issues/detail?id=120103...
[2] https://bugs.chromium.org/p/chromium/issues/detail?id=132323...
[3] https://source.chromium.org/chromium/chromium/src/+/main:bas...
unsafedo RustE esse tipo de código foi literalmente uma das motivações originais para a criação do Rust. Afinal, a linguagem foi projetada desde o início pensando em implementação de navegadores
O inverso, chamar uma linguagem de script a partir de uma linguagem rápida, também é possível. Hoje todo mundo está empolgado com wasm, mas há cerca de 20 anos jogos de computador já usam lua para esse fim. Jogos talvez sejam a maior categoria de software sensível a desempenho
Boa parte do código de UI do Chrome é, pelo menos, feita em Web UI. Hoje eu diria que deveriam considerar typescript para mais trabalhos de orquestração internos do navegador. É uma estratégia validada pelo Electron
Mas o rumo atual parece estar mesmo mais para o MiraclePtr
raw_ptré, na prática, um wrapper de ponteiro inteligente que mitiga a maioria das explorações de use-after-free: https://security.googleblog.com/2022/09/use-after-freedom-mi...Transformei isso em uma visualização em treemap[1]: https://vrp-treemap.surge.sh/
A biblioteca de treemap foi criada pelo veterano do Chrome evmar, que também está nesta thread
Visualização muito limpa. Usa um pouco de CPU a mais ao expandir áreas, mas seria bom se a equipe do Chrome tivesse algo parecido internamente
Por assim dizer, parece realmente útil para entender a superfície de ataque
Ideia muito legal e implementação boa
Os dados brutos estão em algum lugar? Valeria tentar também sunburst ou treemap
Como isso provavelmente chega até o nível de diff, acho que seria interessante ponderar pelo número de linhas de código alteradas. Por exemplo, se 10 linhas mudaram no arquivo A e 1 linha no arquivo B, a maior parte do bug está no arquivo A, então 1/11 da recompensa seria atribuída ao arquivo A?
Ou poderia ser distribuído com base em linhas alteradas / total de linhas do arquivo. Assim daria para ver quanto cada arquivo tem de bugs com uma etiqueta de valor
Seria bom mostrar também a recompensa média por arquivo em cada nó
Um detalhe, mas acho melhor não incluir arquivos DEPS, AUTHORS e BUILD.gn
Que tal uma versão normalizada pelo número de linhas de código?