Date: Sat, 21 Mar 2015 23:01:31 -0400 From: Daniel Micay <danielmicay@...il.com> To: oss-security@...ts.openwall.com Subject: Re: CVE for Kali Linux On 21/03/15 09:59 PM, Kurt Seifried wrote: > From RISKS, looks like it needs a CVE > > Date: Tue, 17 Mar 2015 07:37:50 -0700 > From: Henry Baker <hbaker1@...eline.com> > Subject: Kali Linux security is a joke! > > FYI -- Your best chance to hack the hackers... > > "Downloading Kali Linux" > > "Alert! Always make certain you are downloading Kali Linux from official > sources, as well as verifying md5sums against official values. It would > be easy for a malicious entity to modify a Kali install to contain > malicious code, and host it unofficially." > http://docs.kali.org/category/introduction > > --- > > No kidding! > > So how come whenever you do apt-get install in Kali Linux, it accesses > http://security.kali.org and http://http.kali.org ?? > > Hasn't Kali heard about MITM attacks against http ?? Using HTTPS for package downloads would only make it harder to figure out which packages are installed on the system. A dedicated attacker could figure this out based on side channels over time and I'm not at all convinced that it's valuable information anyway. There are usually other ways of distinguishing between different client/server software and it's not like attacking Thunderbird with a mutt imap exploit is going to trigger any kind of alert... Community distributions like Debian and Arch rely heavily on completely untrusted third party mirrors. That's probably even true of many with commercial support. At some point, someone in the computer science club at $UNIVERSITY sets up a cron job on a machine that many people probably have access to anyway. The people who set up most of the mirrors probably don't even have access to them anymore. Is there really trust between the client and mirror that's worth securing? > What's the point of verifying md5 sums against "official values", if Kali > can't even get the "official values" securely ?? Obtaining the initial ISO is a different issue from the package security model. They seem to use SHA1 anyway. Perhaps they used MD5 some time ago and the summary on the main page was never updated. Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ