- Detalhes
- Escrito por Nícolas Wildner
O relatório do incidente de invasão do repositório do Gentoo já está disponível. Em detalhes na Wiki (fonte) que traduzimos aqui, podemos ter uma ideia da extensão do que aconteceu.
Sumário
Uma entidade desconhecida ganhou controle de uma conta admin da Organização Gentoo no Github e removeu acesso de todos os desenvolvedores. Esta efetuou várias alterações de conteúdo. Os Desenvolvedores e responsáveis pela Infraestrutura do Gentoo escalaram o incidente para a equipe do Github que congelou a Organização Gentoo. O Gentoo readquiriu controle a sua Organização no Github e então reverteu os commits ruins e conteúdo alterado.
Impacto
- Aproximadamente 5 dias de repositório indisponível no Github.
- Pull requests CI fora; apenas branch master disponível para novos incidentes.
- O Projeto Gentoo Proxy Maintainers foi impactado já que diversos contribuidores do proxy-maint utilizam o GitHub para criar PRs.
- A entidade tentou deletar conteúdo adicionando "rm -fr" a vários repositórios; contudo, o código não foi executado devido a diversos gatilhos de proteção.
- Desenvolvimento que não dependia do proxy-maint continuou normalmente; mais de 700 commits foram feitos durante o incidente.
Conteúdo malicioso
Clones dos seguintes repositórios podem possuir conteúdo malicioso. O Gentoo recomenda recriar estes de um novo clone caso você tenha utilizado estes durante o período do ataque.
- gentoo/gentoo: (2018-06-28 20:38 - 2018-06-29 06:58)
- gentoo/musl: (2018-06-28 20:56 - 2018-06-29 06:59)
- gentoo/systemd: (2018-06-28 21:07 - 2018-06-29 06:57)
Causa Raiz
O atacante obteve acesso a uma senha de administrador de organização. Evidencias coletadas sugerem que um schema de senhas vazados do site tornou fácil a descoberta de senhas de páginas não relacionadas.
Lições aprendidas
Parte boa
- Time do Gentoo reportou rapidamente os problemas.
- GitHub respondeu rapidamente ocultando a organização impactada.
- Gentoo removeu rapidamente o acesso da conta invasora após localizado o acesso.
- GitHub forneceu logs de auditoria que auxiliaram a mapear o incidente.
Parte ruim
- Comunicação inicial não foi clara e teve falta de detalhe em duas áreas.
- Como os usuários poderão verificar suas árvores para garantir uma cópia limpa?
- Plano de ação prevendo que, mesmo recebendo commits maliciosos tais comimts não executem no usuário.
- A comunicação veio por 3 vias (www.gentoo.org, infra-status.gentoo.org e listas de email. Mais tarde a wiki foi adicionada e o cenário ficou inconsistente quando a fonte primária de atualizações.
- GitHub falhou em bloquear os repositórios através do git, resultando em commits maliciosos acessíveis externamente. O Gentoo teve que executar um force-push assim que descobriu o problema.
- Procedimentos de revogação de credenciais foram incompletos.
- Não havia um backup dos detalhes da Organização Gentoo no GitHub.
- O repositório systemd não é espelhado do Gentoo, armazenado diretamente no GitHub.
Itens de sorte
- Diversos Desenvolvedores Gentoo possuem contatos pessoais no GitHub, e na indústria da segurança isto pode ser de grande valia para a rápida resolução de um incidente.
- O ataque foi barulhento; remover todos os desenvolvedores causou notificações por email. Por conta da credencial adquirida no repositório, um ataque mais quieto teria provocado uma janela de oportunidade maior.
- O método usado pelos atacantes para enviar os commits (push forçado) fez o consumo downstream saltar aos olhos em notoriedade; isto também fez com que o git não agisse silenciosamente durante pulls em checkouts já existentes.
Fonte: wiki/Github/2018-06-28
Add a comment- Detalhes
- Escrito por Nícolas Wildner
No Arch Linux o repositório de usuários é a forma de obtenção de pacotes similar aos PPAs do Ubuntu, se chama Arch User Repository (AUR) e é o lugar onde pacotes "semi prontos" são hospedados.
Utilizamos o termo "semi prontos" para denotar que pacotes hospedados no AUR não são tecnicamente pacotes binários. São fontes com o arquivo de instrução PKGBUILD que será lido pelo comando makepkg -si. Este utilitário interpretará as instruções criando um pacote binário instalável com base nos fontes que você baixou através de download direto ou usando o git. Contudo, a responsabilidade por manter os pacotes atualizados, verificar problemas de segurança, identificar órfãos e resolver dependências recai no usuário e é aí que entram os "helpers do AUR".
O yaourt é um helper famoso e infelizmente é um dos menos seguros, mais usados e mais problemáticos. Ele não faz diversas validações de segurança (ver "helpers do AUR"), possui linha de comando ambígua que induz ao erro e pede senhas de usuário e de root durante instalações em mensagens não tão claras. Felizmente as notícias que rondavam as mídias do Arch Linux confirmaram e ele foi descontinuado. Uma opção melhor e muito mais segura de helper é o aurman.
Migrar para o aurman é simples. Instruções:
# pacman -R yaourt$ git clone https://aur.archlinux.org/aurman.git$ cd aurman$ makepkg -si
Daqui pra frente é só usar o aurman para buscar e instalar pacotes AUR utilizando a mesma sintaxe do gerenciador pacman. Além de fazer o trabalho de compilação e resolução de dependências cruzadas (pacotes convencionais x AUR) ele categoriza os pacotes por popularidade (já que o mesmo pacote pode vir de usuários diferentes), trabalha com chaves gpg e faz controles de segurança e limpeza de pacotes órfãos ou desnecessários através de sugestões em tela antes do processo de instalação ou atualização de pacotes AUR.
- Detalhes
- Escrito por André Machado
Entre os dias 2 e 4 de Julho de 2.008, o estado de São Paulo viveu uma situação apocalíptica e, até então, inimaginável: a Telefônica (hoje, Vivo), maior provedor de internet do estado, sofrera uma misteriosa pane que deixaria milhões de usuários do serviço, no maior estado do país, fora da rede mundial de computadores.
Add a commentLeia mais: Há 10 anos, "apagão da Telefônica" deixava São Paulo off-line
- Detalhes
- Escrito por Nícolas Wildner
A Fundação NetBSD tem o prazer de anunciar o contrato de verão de 2018 com Philip Nelson (phil%NetBSD.org@localhost) para atualizar a pilha IEEE 802.11 com base no código existente no FreeBSD. Os objetivos do projeto são:
- Minimizar as diferenças entre FreeBSD e NetBSD em suas pilhas IEEE 802.11 para tornar atualizações futuras mais fáceis.
- Adicionar suporte aos novos protocolos 802.11N e 802.11AC
- Melhorias no suporte SMP na pilha IEEE 802.11
- Suporte ao Virtual Access Point (VAP).
- Atualizar tantos drivers de interfaces wifi quanto o tempo permitir para a nova pilha IEEE 802.11 e VAP.
Status sobre o andamento da tarefa serão reportados semanalmente em tech-net%NetBSD.org@localhost durante o decorrer do contrato.
Fonte: Lista tech-net do NetBSD
Add a comment- Detalhes
- Escrito por Nícolas Wildner
Nos seis anos de existência do serviço Google Drive o Linux nunca foi agraciado pela Google com um cliente oficial. Em 2015, algumas supostas fotos do Google Drive rodando nativamente no Ubuntu vazaram na internet. Desde então, nenhuma atualização foi dada quanto ao assunto. Usuários Linux utilizam softwares de terceiros ou desenvolvidos por comunidades de ambientes de desktop como o conector do Nautilus/Gnome (pacote gnome-online-accounts) em interfaces GTK, KIO GDrive para KDE, clientes web (cof,cof,cof... gambiarras) para o Deepin Desktop, ou clientes proprietários como o Insync e o overGrive. Também há opções cli como o gdrive apesar de teoricamente ser um projeto morto.
O GCSF é uma nova opção de sistema de arquivos através da userspace (FUSE) que permite o acesso a uma conta Google Drive como se fosse um ponto de montagem no Linux. Os pré-requisitos para compilação do software no Ubuntu Linux são o pacote libfuse-dev e a árvore estável do Rust que pode ser encontrada aqui. Com base nesta informação, deve ser relativamente fácil para usuários de outras distribuições criarem um procedimento de instalação, e como a maioria dos sistemas operacionais da família BSD também possuem estes softwares em suas árvores de pacotes, deve ser relativamente fácil portar o GCFS ou rodar o software sem a necessidade de adequações.
Depois de inicializar e montar o Drive através do comando gcsf mount /mnt/dir/de/sua/escolha, os arquivos são exibidos de forma transparente para o usuário:
No Thunar:
Fonte: Lobste.rs
Add a comment
- Detalhes
- Escrito por Nícolas Wildner
O Wireguard é um software de VPN embutido no Linux que anda ganhando tração. Junto a este fato, sabemos que as VPNs tem se tornado cruciais nos dias de hoje para trespassar restrições geográficas mantendo as informações relativamente seguras aos espiões e infelizmente as soluções de VPN mais populares existentes tem seus problemas apesar da sua popularidade.
Soluções conhecidas como OpenVPN e IPsec são complexas e isto dificulta sua auditoria. Além disto, a OpenVPN possui código na userspace tornando-a lenta já que cada pacote precisa ser copiado numa série de trocas de contexto. Esta é uma imagem que mostra a diferença em quantidade de linhas de código de cada solução:
Como já vimos antes, a VPN Wireguard é a nova solução emergente que oferece facilidade no uso, criptografia atualizada e facilidade de auditoria. Recebeu a "benção" do desenvolvedor e mantenedor Greg KH, um dos líderes no fluxo do desenvolvimento do Kernel, e como vimos está ganhando um bom número de clientes para outras plataformas. O desenvolvedor Jason Donenfeld está trabalhando para que o WireGuard seja incluído na mainline do Kernel em breve.
Além das figuras técnicas endossando o uso do Wireguard o Senador Ron Wyden, democrata do estado de Oregon, escreveu uma carta aberta ao NIST (National Institute of Standards and Technology) desencorajando o uso de tecnologias como OpenVPN e IPsec por agentes do governo, endossando a tecnologia do Wireguard e cobrando um posicionamento deste instituto para um estudo de viabilidade da adoção do Wireguard como uma solução padrão. Os motivos utilizados por Wyden são bons do ponto de vista técnico: Incorporação no Kernel, simplicidade de projeto/design, quantidade reduzida de opções criptográficas (removendo também código defasado e cifras menos seguras).
Fonte: XDA-Developers
Add a comment- Detalhes
- Escrito por André Machado
Após um mês de testes beta, a nova versão do Linux Mint, codinome "Tara", está disponível para download. De forma tradicional, a nova versão, que é o primeiro grande lançamento da distro em dois anos, vem em três edições, com os ambientes Cinnamon, XFCE e MATE disponíveis.
Dentre os principais novos recursos, podemos citar o Timeshift, uma nova ferramenta de backup que facilita criar e restaurar cópias de segurança dos dados pessoais e dos aplicativos dos usuários, um novo aplicativo de boas-vindas, para auxiliar novos usuários, o novo Software Manager, que permite a instalação de aplicativos Flatpak e um novo tema, chamado Mint-Y, que dá ao ambiente desktop um visual mais polido. O sistema vem com o kernel Linux 4.15 e traz um suporte melhorado para HiDPI e suporte a fontes da Microsoft.
A nova versão é baseada no Ubuntu 18.04 e é suportada até 2.023. Seus requisitos mínimos são: 1GB de RAM (2GB recomendados). 15GB de espaço em disco (20GB recomendados) e uma resolução mínima de 1.024x768.
Fonte: OMG! Ubuntu!
Add a comment- Detalhes
- Escrito por Nícolas Wildner
Uma das vantagens do compilador Clang(LLVM) é sua melhor integração com o autocompletar. Martin Liška da SUSE começou neste ano uma empreitada que cria o argumento --complete no GCC para alimentar os scripts de autocompletar da Bash.
Esta funcionalidade está prevista para o próximo ano com a chegada da GCC9 e adicionará suporte também as opções de argumentos tornando a vida de quem utiliza este compilador mais fácil. Exemplos:
1)$ gcc -fsanitize=address bounds enum integer-divide-by-zero nonnull-attribute pointer-compare return shift-base thread vla-boundalignment bounds-strict float-cast-overflow kernel-address null pointer-overflow returns-nonnull-attribute shift-exponent undefined vptrbool builtin float-divide-by-zero leak object-size pointer-subtract shift signed-integer-overflow unreachable 2)$ gcc -fno-ipa--fno-ipa-bit-cp -fno-ipa-cp-alignment -fno-ipa-icf -fno-ipa-icf-variables -fno-ipa-profile -fno-ipa-pure-const -fno-ipa-reference -fno-ipa-struct-reorg -fno-ipa-cp -fno-ipa-cp-clone -fno-ipa-icf-functions -fno-ipa-matrix-reorg -fno-ipa-pta -fno-ipa-ra -fno-ipa-sra -fno-ipa-vrp 3)$ gcc --param=lto-lto-max-partition lto-min-partition lto-partitions 4)$ gcc --param lto-lto-max-partition lto-min-partition lto-partitions
Fonte: Phoronix
Add a comment- Detalhes
- Escrito por Nícolas Wildner
Para aqueles que ainda sentem vontade de usar este sistema de arquivos "matador", o Reiser4 foi portado para o kernel Linux 4.17.
Nada novo aqui: Sem melhorias ou novas funcionalidades, apenas compatibilização com esta versão de kernel. Também não há planos para colocar o Reiser4 na mainline do kernel já que todos os patrocinadores grandes do projeto vazaram(porque será?) e a maioria dos sistemas de arquivos de hoje em dia já possuem as funcionalidades do Reiser4. Os patches são postados regularmente em cada versão de kernel no seguinte repositório da SourceForge.
Me lembro como se fosse ontem dos anos 2000-2006 onde diversos fóruns sugeriam o uso do Reiserfs para o /home já que possuía journaling de metadados, acls estendidas do POSIX, expansão online e redução offline sem a necessidade da camada do lvm e tail packing. Era tecnicamente superior ao ext2 disponível na época mas...
Fonte: Phoronix
Add a comment- Detalhes
- Escrito por André Machado
Os administradores da distribuição Gentoo relatam em seu site que, no dia de hoje (28/06/2018), às 20:20 UTC (17:20, horário de Brasília), indivíduos desconhecidos ganharam controle da organização Gentoo no GitHub e modificaram o conteúdo dos repositórios, bem como as páginas lá.
Os administradores ainda estão trabalhando para determinar a extensão exata dos danos e recuperar o controle da organização e de seus repositórios. Todo o código do Gentoo hospedado no GitHub deve, no momento, ser considerado comprometido.
A boa notícia é que esse incidente não afeta o código hospedado na infraestrutura do Gentoo. Uma vez que o repositório ebuild mestre está hospedado na própria infraestrutura da organização e o GitHub é apenas um espelho para ela, os usuários da distribuição estarão bem contanto que utilizem rsync ou webrsync a partir do gentoo.org. Além disso, os repositórios gentoo-mirror incluindo metadados estão hospedados sob uma organização Gentoo separada e provavelmente não foram afetados.
Fonte: https://it.slashdot.org/story/18/06/28/2240254/github-gentoo-organization-hacked
Add a commentPágina 8 de 17
