some feedback about security from the user's point of view
Hi, quite some people around me use debian with view of creating secure encrypted systems. Consider for example in france boum.org, who have published a book about computer security which advises people to use debian. Those people turn to me with questions about how safe things are and want advice for their practices. Some weeks ago I decided to have a look at debian and quite soon ran into questions and problems considering the security of debian. I would like to share some of those questions, remarks in this mail in the hope of stimulating a discussion and hopefully a more secure future for all of us as quite a few are going to need it and depend on it. Something that immediately drew my attention was the choice of debian.orgnot to have a certified SSL connection. I can see the reasons for this, and I am also aware of the limits in SSL, but I still want to raise the issue of being able to obtain a copy of debian with a higher degree of security than plain http. I set of to try to do that and the following describes my experiences: I ended on this page: http://debian.org/distrib/ which is quite short and I quite some information on this page http://debian.org/CD/http-ftp/ is also important for people using other methods of download like torrents however they don't get to see it (e.g. you only need disc 1 to install a standard debian system). Information regarding verifying the downloads is completely lacking from these pages which occurs to me to be odd. I finally found via google that it is in the faq: http://debian.org/CD/faq/#verify The instructions here are quite problematic. First of all, they advise the use of md5 which has been broken http://en.wikipedia.org/wiki/MD5#Security. It occurs to me that changing this documentation to use another hash would be trivial. If security advice from debian suggests the use of md5, it also makes me wonder where else in the debian operating or package system md5 still gets used. It doesn't make me feel safe if an operating system does not have a policy to replace all occurrences of a certain cryptographic function after it has been broken. What is the position of the debian development/security team on this? Next the instructions in the faq suggest that the user can verify the correctness of these hashes with the pgp signature. This makes 2 problematic assumptions. First it assumes that users are in the web of trust and have a means of verifying the debian pgp key. Secondly it assumes that users understand the way a web of trust works and also is aware of the limits and vulnerabilities of it, as well as understands how to use it correctly. Considering that more and more less geeky people start to use linux systems, those assumptions exclude a growing group of users which are not directly linked to the debian development team in the web of trust, and who often don't even have pgp keys, or friends who do to allow them to get access to the web of trust. Personally I am not in the web of trust, and I don't think I personally know anyone who is. In conclusion of this, the highest level of security with which I and many others can obtain debian *in practice* is plain http. To make matters worse, this limitation is not obvious. This entry gives the impression that the user verifies something, and only the knowledgeable user will realise that they aren't if they cannot verify the pgp key. If it is considered useful to rewrite the faq entry on verification of the iso's and no one can be found to do it, let me know and I could make a proposition. Another general problem is that debian.org does not give much information about the development team's policies or attitudes vs security. No statement is made for example about what efforts are being taken to prevent the private pgp key from being compromised. In general, there is a security page on the debian.org website which has some very well sounding opening phrases but which gives very meager information on how the debian development team needs to behave in order to prevent security compromises. Neither does it give a list of past problems and the actions taken to prevent them in the future. See for example this quote from http://lists.debian.org/debian-security/2011/01/msg2.html where this issue has already been discussed before: HTTPS is going to make it harder for man-in-the-middle shenanigans, but that is only part of the path from the developer to the user. One also has to consider whether the project's servers have been tampered with - which tends to be the much more common attack (both Debian and RedHat / Fedora have experiences with this). If thing like this happen, I like to know that they did and what has been done to prevent them in the future. Does debian have a policy requiring an official report to be written and published about security incidents? In conclusion if I as a user have to make some assessment about the security level of debian and I have to use the website to do that, debian
Re: some feedback about security from the user's point of view
Hi all, a small disclaimer first, I am not affiliated with debian in any way, I am, as the original author would have put it a user. I would like to play devil's advocate in a few of the quite interesting points that Naja raises: 1) Why is *getting* debian over plain HTTP such a big issue? Assuming that even you get a tampered .iso, it is trivial to verify that it is not the genuine one, even in using a broken hash algorithm such as MD5. SSL-enabling all downloads from Debian would have the unfortunate side effects of increasing the load on the servers, requiring more budget from the Debian team, as well as meaning losing a few mirrors around the globe. Personally, I view it as a reasonable risk, provided that the end user verifies the .iso image before installing. 2) Regarding MD5, while indeed it has been broken, is it not sufficient for simple checksumming purposes? I have not looked throughly into this so please feel free to correct me but how practical would have been for someone to create a meaningful debian .iso AND introduce backdoors to it AND create a MD5 sum that matches the original one? Are there any examples of it in the wild? Having said that, I am all for the use of SHA256 or better in all newer examples/hashes, I cannot stress how strongly I agree, even for the sake of modernizing. 3) Regarding policies, I think that unfortunately Debian has a bad record (cough, cough, openSSL PRNG circa 2008) so what is the current situation? This is partially mitigated by the work performed by the security team who kill bugs on a daily basis. Granted, this is a bit after the fact but bugs get killed. Again, I fully agree with the author however how such a centralized management tool such as policies can be applied to an all open-source distribution, such as Debian? Does that by extension means that Debian developers have to proactively seek out possible security bugs in other's people code? Having said the above, the question is how could someone help by donating time/skills to address the points raised by the original poster? Cheers! On 01/23/2011 06:35 PM, Naja Melan wrote: Hi, quite some people around me use debian with view of creating secure encrypted systems. Consider for example in france boum.org, who have published a book about computer security which advises people to use debian. Those people turn to me with questions about how safe things are and want advice for their practices. Some weeks ago I decided to have a look at debian and quite soon ran into questions and problems considering the security of debian. I would like to share some of those questions, remarks in this mail in the hope of stimulating a discussion and hopefully a more secure future for all of us as quite a few are going to need it and depend on it. Something that immediately drew my attention was the choice of debian.orgnot to have a certified SSL connection. I can see the reasons for this, and I am also aware of the limits in SSL, but I still want to raise the issue of being able to obtain a copy of debian with a higher degree of security than plain http. I set of to try to do that and the following describes my experiences: I ended on this page: http://debian.org/distrib/ which is quite short and I quite some information on this page http://debian.org/CD/http-ftp/ is also important for people using other methods of download like torrents however they don't get to see it (e.g. you only need disc 1 to install a standard debian system). Information regarding verifying the downloads is completely lacking from these pages which occurs to me to be odd. I finally found via google that it is in the faq: http://debian.org/CD/faq/#verify The instructions here are quite problematic. First of all, they advise the use of md5 which has been broken http://en.wikipedia.org/wiki/MD5#Security. It occurs to me that changing this documentation to use another hash would be trivial. If security advice from debian suggests the use of md5, it also makes me wonder where else in the debian operating or package system md5 still gets used. It doesn't make me feel safe if an operating system does not have a policy to replace all occurrences of a certain cryptographic function after it has been broken. What is the position of the debian development/security team on this? Next the instructions in the faq suggest that the user can verify the correctness of these hashes with the pgp signature. This makes 2 problematic assumptions. First it assumes that users are in the web of trust and have a means of verifying the debian pgp key. Secondly it assumes that users understand the way a web of trust works and also is aware of the limits and vulnerabilities of it, as well as understands how to use it correctly. Considering that more and more less geeky people start to use linux systems, those assumptions exclude a growing group of users which are not directly linked to the debian development team in the
Re: some feedback about security from the user's point of view
On dim., 2011-01-23 at 17:35 +0100, Naja Melan wrote: Some weeks ago I decided to have a look at debian and quite soon ran into questions and problems considering the security of debian. I would like to share some of those questions, remarks in this mail in the hope of stimulating a discussion and hopefully a more secure future for all of us as quite a few are going to need it and depend on it. Asking the same questions again and again won't really help, in my opinion. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: some feedback about security from the user's point of view
On Sun, 2011-01-23 at 19:34 +0200, AK wrote: a small disclaimer first, I am not affiliated with debian in any way, I am, as the original author would have put it a user. The same goes for me, so I suppose my remarks should be taken with a comparably-sized grain of salt. :) That said: 1) Why is *getting* debian over plain HTTP such a big issue? Assuming that even you get a tampered .iso, it is trivial to verify that it is not the genuine one, even in using a broken hash algorithm such as MD5. SSL-enabling all downloads from Debian would have the unfortunate side effects of increasing the load on the servers, requiring more budget from the Debian team, as well as meaning losing a few mirrors around the globe. Personally, I view it as a reasonable risk, provided that the end user verifies the .iso image before installing. I think the resistance to the idea isn't so much from the fact that the use of SSL is a panacea -- there are obviously numerous ways that one can wind up with a compromised OS, the initial download is but one of them -- but rather that it would provide a good first layer of protection against tampering. While I have done no measurements of this myself, there seems to be some [1] consensus [2] that SSL doesn't actually impose nearly as much overhead as people think it does, especially if you're dealing with long-lasting connections. Obviously there is a good bit of management overhead associated with deployment and administration, but at least from the performance standpoint it seems (to my untrained eye) like the SSL == serious performance hit issue has been at least partially conquered by Moore's law. From one of the Google engineer's postings [2] on the subject: In January this year (2010), Gmail switched to using HTTPS for everything by default. [...] In order to do this we had to deploy no additional machines and no special hardware. On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that. If you stop reading now you only need to remember one thing: SSL/TLS is not computationally expensive any more. [1] http://stackoverflow.com/questions/548029/how-much-overhead-does-ssl-impose [2] http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html Regarding MD5, while indeed it has been broken, is it not sufficient for simple checksumming purposes? I have not looked throughly into this so please feel free to correct me but how practical would have been for someone to create a meaningful debian .iso AND introduce backdoors to it AND create a MD5 sum that matches the original one? Are there any examples of it in the wild? I don't know of any examples for ISO images, but there definitely have been PoCs released capable of generating collisions for other types of file. Of course I imagine that anyone who actually 1) can produce and 2) does produce such collisions for ISOs is probably doing so for nefarious purposes, and is thus not terribly eager to make public the existence of whatever tools they created/used... There are already SHA1, SHA256, and SHA512 sums available for the images right now, so really the removal of MD5 would be more a show of good faith than a practical improvement to security. Of course if any documentation actually recommends the use of MD5 over the other digests... well that's another matter. Cheers, Rob -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1295805878.2295.45.camel@kestrel
Re: some feedback about security from the user's point of view
Thanks for the reply and the links Robert. I agree with your point on SSL/TLS not being as computationally expensive as it used to be, however (as you correctly state) it can be more of an issue regarding management/resources, as well as red tape. Regarding Google's statement with SSL/TLS cost being negligible, while I empirically agree with this one (e.g. in our project's infrastructure un-accelerated SSL overhead was minimal, even though by default we employ the strongest cipher suits of it), again this falls into a matter of integrating SSL into existing infrastructure, a cost that might not be readily available justifiable to a bureaucratic environment, such as a university. To put it a bit colloquially, downloading Debian ISOs over encrypted or unencrypted HTTP will not cause any fluctuation on the amount of daily sleep I get :) Regarding the MD5 sum example and certain released PoCs: producing two random files with identical MD5 sums is one thing, introducing a meaningful backdoor (which means deterministic change) or ten in a Debian iso and generating an iso file which is similar in size to the original one and has an identical MD5 sum might be a tad more computationally difficult (this is my estimation), especially for something as short-lived as a Linux CD image. Adding into account that this trick can easily be rendered useless if the end user chooses let's say SHA256 as opposed to MD5 to verify the downloaded file (and banished altogether by a simple announcement by Debian team along the lines of please use SHA256 to verify all downloads from us. I fully agree with the removal of MD5 as a sign of keeping with the times though. On 01/23/2011 08:04 PM, Robert Tomsick wrote: On Sun, 2011-01-23 at 19:34 +0200, AK wrote: a small disclaimer first, I am not affiliated with debian in any way, I am, as the original author would have put it a user. The same goes for me, so I suppose my remarks should be taken with a comparably-sized grain of salt. :) That said: 1) Why is *getting* debian over plain HTTP such a big issue? Assuming that even you get a tampered .iso, it is trivial to verify that it is not the genuine one, even in using a broken hash algorithm such as MD5. SSL-enabling all downloads from Debian would have the unfortunate side effects of increasing the load on the servers, requiring more budget from the Debian team, as well as meaning losing a few mirrors around the globe. Personally, I view it as a reasonable risk, provided that the end user verifies the .iso image before installing. I think the resistance to the idea isn't so much from the fact that the use of SSL is a panacea -- there are obviously numerous ways that one can wind up with a compromised OS, the initial download is but one of them -- but rather that it would provide a good first layer of protection against tampering. While I have done no measurements of this myself, there seems to be some [1] consensus [2] that SSL doesn't actually impose nearly as much overhead as people think it does, especially if you're dealing with long-lasting connections. Obviously there is a good bit of management overhead associated with deployment and administration, but at least from the performance standpoint it seems (to my untrained eye) like the SSL == serious performance hit issue has been at least partially conquered by Moore's law. From one of the Google engineer's postings [2] on the subject: In January this year (2010), Gmail switched to using HTTPS for everything by default. [...] In order to do this we had to deploy no additional machines and no special hardware. On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that. If you stop reading now you only need to remember one thing: SSL/TLS is not computationally expensive any more. [1] http://stackoverflow.com/questions/548029/how-much-overhead-does-ssl-impose [2] http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html Regarding MD5, while indeed it has been broken, is it not sufficient for simple checksumming purposes? I have not looked throughly into this so please feel free to correct me but how practical would have been for someone to create a meaningful debian .iso AND introduce backdoors to it AND create a MD5 sum that matches the original one? Are there any examples of it in the wild? I don't know of any examples for ISO images, but there definitely have been PoCs released capable of generating collisions for other types of file. Of course I imagine that anyone who actually 1) can produce and 2) does produce such collisions for ISOs is probably doing so for nefarious purposes, and is thus not terribly eager to make public the existence of whatever tools they
Re: some feedback about security from the user's point of view
In 4d3c66a0.80...@gmail.com, AK wrote: 3) Regarding policies, I think that unfortunately Debian has a bad record (cough, cough, openSSL PRNG circa 2008) The patch file that introduced that security issue can be broken into two parts that don't overlap: (a) the part that fixed the policy violation and (b) the part that undermined the security. Initially, part (a) was written based on a recommendation from an automated tool. Then a similar block of code was found that hadn't been reported using the automated tool. The code looked so similar, someone thought that it the same changes should be applied there. Those copied changes are part (b), and deeper analysis indicated that part (b) was not only not needed (the automated tool was correct not to report an issue) but was actively undermining security. Slavish adherence to policy was not the problem. Bad policy was not the problem. A human mistake was made and it because a long-standing problem. The instructions here are quite problematic. First of all, they advise the use of md5 which has been broken http://en.wikipedia.org/wiki/MD5#Security. It occurs to me that changing this documentation to use another hash would be trivial. If security advice from debian suggests the use of md5, it also makes me wonder where else in the debian operating or package system md5 still gets used. It doesn't make me feel safe if an operating system does not have a policy to replace all occurrences of a certain cryptographic function after it has been broken. What is the position of the debian development/security team on this? Salted MD5 is not broken, and it is currently used for password hashing. I don't recommend using MD5 to verify the CD images, since there are some pretty nasty chosen prefix collision attacks. But, SHA-1 and SHA-2 family of hashes are also available. MD5 verification of a CD image is still better than nothing, at least for now. In conclusion of this, the highest level of security with which I and many others can obtain debian *in practice* is plain http. I disagree with that assertion. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: some feedback about security from the user's point of view
Quoting Naja Melan (najame...@gmail.com): Some weeks ago I decided to have a look at debian and quite soon ran into questions and problems considering the security of debian. I would like to share some of those questions, remarks in this mail in the hope of stimulating a discussion[...] It seems frankly difficult to distinguish between that and a troll who doesn't do his homework. I don't think you even understand the concept of threat models, to start with, and this isn't an appropriate place to get taught basic concepts. I suspect the Security Team are carefully sitting on their hands and muttering 'I really don't have time to educate this person', just like last time you tried this. -- Cheers, Rick (Not speaking for anyone; just a sysadmin) Moen r...@linuxmafia.com McQ! (4x80) -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110123215753.gk2...@linuxmafia.com
Re: some feedback about security from the user's point of view
On Sun, Jan 23, 2011 at 12:34 PM, AK wrote: Hi all, a small disclaimer first, I am not affiliated with debian in any way, I am, as the original author would have put it a user. I would like to play devil's advocate in a few of the quite interesting points that Naja raises: 1) Why is *getting* debian over plain HTTP such a big issue? Assuming that even you get a tampered .iso, it is trivial to verify that it is not the genuine one, even in using a broken hash algorithm such as MD5. SSL-enabling all downloads from Debian would have the unfortunate side effects of increasing the load on the servers, requiring more budget from the Debian team, as well as meaning losing a few mirrors around the globe. Personally, I view it as a reasonable risk, provided that the end user verifies the .iso image before installing. There is no need to worry about additional load on the mirrors since the only thing that needs to be verifiable are the checksums themselves, and that could easily be hosted on a centralized https server separate from the mirror system. Having said the above, the question is how could someone help by donating time/skills to address the points raised by the original poster? This is one of the downsides of an all-volunteer organization: someone actually needs to be interested, self-motivated, and willing to work on the issue at hand. However, in this case it will be hard for any non-DD to effect any change directly. You will need to work with appropriate teams. One thing that could be done is to draft up some better wording for the faq and media download pages, then work with the www team to get those changes implemented. Also, a discussion could be started with SPI to see if they are willing to purchase a CA cert. That would at least allow users with implicit trust in the CA system to get a nice fuzzy feeling when they see the lock icon when downloading checksums. Anyway, to sum up, things can certainly be improved; it just requires someone to step up and work with the affected teams to make the desired changes. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktik1ghfan0das1vrp4gn9libqg3jlauayvavw...@mail.gmail.com
Re: some feedback about security from the user's point of view
On Sun, 2011-01-23 at 19:32 -0500, Michael Gilbert wrote: Also, a discussion could be started with SPI to see if they are willing to purchase a CA cert. That would at least allow users with implicit trust in the CA system to get a nice fuzzy feeling when they see the lock icon when downloading checksums. It might be worth checking with the various major CAs to see if they'd be willing to issue a cert. for free. I know Thawte has issued them for free to community projects (kernel.org being a notable example), and I would assume that Debian is certainly well-enough established to be eligible for one. -Rob -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1295829625.2295.57.camel@kestrel
Re: some feedback about security from the user's point of view
Michael Gilbert wrote: There is no need to worry about additional load on the mirrors since the only thing that needs to be verifiable are the checksums themselves, and that could easily be hosted on a centralized https server separate from the mirror system. The Debian CDs and the Archive Signing keys can be found at keyring.d.o Additionally, the archive signing key can be found at: https://ftp-master.debian.org/keys.html Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ihinpd$nti$1...@dough.gmane.org
Re: some feedback about security from the user's point of view
On Sun, 23 Jan 2011 20:22:34 -0600 Raphael Geissert wrote: Michael Gilbert wrote: There is no need to worry about additional load on the mirrors since the only thing that needs to be verifiable are the checksums themselves, and that could easily be hosted on a centralized https server separate from the mirror system. The Debian CDs and the Archive Signing keys can be found at keyring.d.o Right, I suppose that even the checksums themselves don't need to be served over https (as long as they're signed by an official key that can be obtained in a secure manner; via web of trust, over https, or otherwise). Additionally, the archive signing key can be found at: https://ftp-master.debian.org/keys.html The problem from Naja's perspective is that the SPI cert was not issued by a CA, and for (some) users outside the web of trust that in itself is a non-starter. In that sense, an official CA cert would be a modest improvement in security (even with all of its flaws/shortcomings); although the ideal solution would be to get the user to become a part of the web of trust. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110123221136.61cc6950.michael.s.gilb...@gmail.com
Re: some feedback about security from the user's point of view
Am Sonntag, 23. Januar 2011, um 20:52:44 schrieb AK: Regarding the MD5 sum example and certain released PoCs: producing two random files with identical MD5 sums is one thing, introducing a meaningful backdoor (which means deterministic change) or ten in a Debian iso and generating an iso file which is similar in size to the original one and has an identical MD5 sum might be a tad more computationally difficult (this is my estimation), especially for something as short-lived as a Linux CD image. With control over a single Debian package (read: when a Debian developer is in on the attack), it could be easily done including plausible deniability for the involved developer: 1. Place a random (but large enough) binary blob into a binary installed by a package. The binary blob in the Debian package as uploaded to the archive is competely harmless and may just look odd (if it was detected, that is). 2. Create a second binary blob with a collision (but with harmful content). This is fairly easy to do if the two blobs are similar save for a small, known-to-collide part. 3. Wait for the uploaded package to appear in an ISO and the MD5 sums to be created 4. Replace the binary blob, the MD5 sum still matches. 5. Give somebody the changed ISO So yes, MD5 should no longer be recommended. best regards, Rene signature.asc Description: This is a digitally signed message part.
