Re: [cryptography] Just how bad is OpenSSL ?
On Mon, Oct 29, 2012 at 10:34 PM, Jeffrey Walton noloa...@gmail.com wrote: On Fri, Oct 26, 2012 at 2:29 PM, John Case c...@sdf.org wrote: I was recently reading the most dangerous code in the world article at stanford: https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html and found the hackernews discussion: http://news.ycombinator.com/item?id=4695350 (interesting discussion and argument about curl library and how often it is badly deployed) And the hackernews discussion led me to OpenSSL is written by monkeys: http://www.peereboom.us/assl/assl/html/openssl.html So, given what is in the stanford report and then reading this rant about openssl, I am wondering just how bad openssl is ? I've never had to implement it or code with it, so I really have no idea. How long has it been understood that it's a mess (if it is indeed a mess) ? How dangerous is it ? If your engineering process includes an SDLC, then OpenSSL has at least two other issues: 1) It can't clean compile with nominal warnings 2) It lacks platform security integration For (1), a clean compile is often a security gate, and I don't like the choice of the Ostrich Algorithm. I wrote to NIST a while back and asked that a clean compile be added as a CMVP requirement, but nothing every came from it. The problem is that I cannot change the source files, so I can't fix the problems flagged by the compiler warning system, dynamic analysis, or static analysis. OpenSSL compiles clean with the following set of flags (under gcc): -Wall -pedantic -DPEDANTIC -Wno-long-long -Wsign-compare -Wmissing-prototypes -Wshadow -Wformat -Werror -DCRYPTO_MDEBUG_ALL -DCRYPTO_MDEBUG_ABORT -DREF_CHECK -DOPENSSL_NO_DEPRECATED you can find this in Configure, in the variable $gcc_devteam_warn. If you can make a case for more/less/different flags it should compile clean under, I'd be happy to fix it (at least in non-frozen branches). I have no idea what you mean by nominal warnings. For example, I know that OpenSSL uses uninitialized data (and *not* in the PRNG path). A bug report was filed and closed won't fix because the members of interest were initialized. I also know the library suffers conversion problems and truncation problems. Pointer? For completeness, here are the GCC switches of interest: * C Code: -Wall -Wextra -Wconversion -Wstrict–overflow -Wformat=2 -Wformat-security Ah, OK, you supply them. I don't have any argument with these, I suspect, but observe that all of them are newer than OpenSSL is. If people want issues like this fixed, they need to raise them :-) * C++ Code (includes C Code warnings): -Woverloaded-virtual -Wreorder -Wsign-promo -Wnon-virtual-dtor * Objective C Code (includes C Code warnings): -Wstrict-selector-match -Wundeclared-selector For item (2), we have some good defenses provided by the platform but they are not used - ASLR, DEP, Stack Canaries, Safe Memory functions etc. Considering how often the library handles untrusted input (the remote host's data should always be considered untrusted) and how often there are parser problems, I would expect these to be mandatory for high integrity software. For completeness, here are the switches for GCC/LD (use as available): * -fPIE/-pie (or –fPIC/-shared) * -fstack-protector-all * FORTIFY_SOURCES=2 * -z,relro, -z,now Again, I wrote to NIST and asked that the CMVP program include platform security integration since I cannot change it after validation. For what its worth, its not just OpenSSL that has these problems. Apparently you think the best way to get a secure platform is to apply pressure through pointless security standards. I'd suggest your efforts might be better spent supplying patches instead. Or, y'know, talking to the authors of the s/w in question. You never know, they might care. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Your GPU's “Fingerprint” Could Lead to New Security Methods
http://h30565.www3.hp.com/t5/Feature-Articles/Your-GPU-s-Fingerprint-Could-Lead-to-New-Security-Methods/ba-p/8418 Your GPU's “Fingerprint” Could Lead to New Security Methods by Andy Patrizio (apatrizio) on 29-10-2012 08:00 AM starlight_dreamstimefree_141720.jpg In the online world, a World of Warcraft account can be worth serious money. With such an incentive, malware is set to steal your WoW login and password, should you become infected. To protect an account, WoW users have the option of purchasing an authenticator for a minor fee of $6.50. Of course, if you lose the authenticator or if it breaks, poof! goes your game access. Security veterans recognize this as two-factor authentication: a password and a separate, physical security device that the owner must have in their possession. While two-factor authentication can greatly increase your security, it also represents another point of vulnerability because you can always lose the device. Researchers in Europe have come up with an alternative. Instead, your computer's graphics processor unit (GPU) would be the authenticator, identifying a user by tying him to his specific GPU. The Physically Unclonable Functions Found in standard PC Components Project, or PUFFIN, say that every GPU has a unique and defining set of characteristics that make each GPU as unique and individual as a snowflake or a fingerprint. These differences are known as a physical unclonable functions (PUF); they can only be detected by software and by knowing where to look. This is how the PUFFIN group found the uniqueness to GPU memory in the first place, since it was looking for PUFs. The PUFFIN group, which specializes in cryptography, uses GPUs for number crunching, since these chips are essentially giant math co-processors. To get higher performance, the PUFFIN group designed an assembly language application and gained access to the static RAM on the GPU. One of the things they did was look at the contents of a GPU’s SRAM to see if the previous contents were still there, explained Dr. Tanja Lange, a professor in the department of Mathematics and Computer Science at Technische Universiteit Eindhoven, in Eindhoven, Holland. What they found looked promising for a PUF. To further investigate the behavior, they joined forces with two other universities, including the University of Chicago, and Intrinsic-ID, a Dutch company specializing in PUFs. The physical layout of SRAM cells is such that each of them falls to a 0 or 1 when unpowered, Dr. Lange explained. The choice depends on tiny manufacturing differences. When the SRAM is powered on, these values stay until drivers overwrite them with data. Like fingerprints, the behavior of falling to 0 or to 1 is not perfectly deterministic, but we know how to deal with noisy data. It was known already that in general SRAM can be used to build PUFs, she said. What this means is the 0s and 1s of SRAM have a unique arrangement to each GPU – which enables your GPU to become your authenticator. A WoW gamer won't need the separate physical authenticator any more, as her GPU can handle authentication for them. Or, on the flip side, a GPU could be the validation that allows only a certain PC to access a certain resource. For example, C-level executives could have their own secured, private space on a corporate network which only they could access, with their PC's GPU acting as authentication. No other PC would be able to access that network space. The PUFFIN group managed to dig into the GPUs to read out the uninitialized memory. It could extract the information from Nvidia GPUs using Nvidia's CUDA language for programming the GPU processor. The researchers have not experimented with GPUs from AMD or Intel yet but they hope to find a similar scenario. In principle, this should apply to anything out there, said Daniel J. Bernstein, a professor of computer science at the University of Illinois at Chicago and also a part-time professor at Technische Universiteit Eindhoven. Whether we can get access from software is a new game for every processor. There's no reason things should be different for AMD and Intel. There should be the same variability in static RAM. Whether we can access it is another question. GPU makers don't want anyone looking at the initialization memory, so it took some effort on the part of the Eindhoven group to get at the memory. Access [to the GPU SRAM] has to be integrated with OS kernel and hypervisor. There's still more steps to be taken. What we have now is a demo that GPUs have this identification information we can access and there are no clear obstacles to using it as security, said Bernstein. But he adds that it's not something that can be dropped into products today. Based on what we've seen so far, it is impossible for anyone to clone the card, said Lange. But turning identity into a full-fledged security mechanism is several steps we have to go through. Indeed, it will require an industry-wide standard
Re: [cryptography] Just how bad is OpenSSL ?
On Tue, Oct 30, 2012 at 5:03 AM, Ben Laurie b...@links.org wrote: On Mon, Oct 29, 2012 at 10:34 PM, Jeffrey Walton noloa...@gmail.com wrote: On Fri, Oct 26, 2012 at 2:29 PM, John Case c...@sdf.org wrote: [SNIP] Apparently you think the best way to get a secure platform is to apply pressure through pointless security standards. I'd suggest your efforts might be better spent supplying patches instead. Or, y'know, talking to the authors of the s/w in question. You never know, they might care. I'm not sure I agree some defenses are pointless. For example, attackers are very clever at building exploits such as ROP gadgets. ASLR and DEP are two of the better defenses we have in this case when a program failed its initial mission of no bugs. I'm not convinced a second line of defense is pointless. And I am aware of userland and kernel leaking addresses at times - I'm just not willing to throw the baby out with the bath water. Jeff ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Just how bad is OpenSSL ?
On Tue, Oct 30, 2012 at 11:09 AM, Jeffrey Walton noloa...@gmail.com wrote: On Tue, Oct 30, 2012 at 5:03 AM, Ben Laurie b...@links.org wrote: On Mon, Oct 29, 2012 at 10:34 PM, Jeffrey Walton noloa...@gmail.com wrote: On Fri, Oct 26, 2012 at 2:29 PM, John Case c...@sdf.org wrote: [SNIP] Apparently you think the best way to get a secure platform is to apply pressure through pointless security standards. I'd suggest your efforts might be better spent supplying patches instead. Or, y'know, talking to the authors of the s/w in question. You never know, they might care. I'm not sure I agree some defenses are pointless. Nor would I, which is why its lucky its not what I said. For example, attackers are very clever at building exploits such as ROP gadgets. ASLR and DEP are two of the better defenses we have in this case when a program failed its initial mission of no bugs. I'm not convinced a second line of defense is pointless. And I am aware of userland and kernel leaking addresses at times - I'm just not willing to throw the baby out with the bath water. Jeff ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Just how bad is OpenSSL ?
On Tue, Oct 30, 2012 at 11:17 AM, Peter Gutmann pgut...@cs.auckland.ac.nz wrote: Ben Laurie b...@links.org writes: Apparently you think the best way to get a secure platform is to apply pressure through pointless security standards. I think that's a bit of an extreme comment on FIPS 140. For one thing it makes for a great measure of how desperate a vendor is to get onto the US government procurement gravy train, so it does have some value. How can it be a great measure of that when OpenSSL has FIPS 140? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Just how bad is OpenSSL ?
On Tue, Oct 30, 2012 at 5:03 AM, Ben Laurie b...@links.org wrote: On Mon, Oct 29, 2012 at 10:34 PM, Jeffrey Walton noloa...@gmail.com wrote: On Fri, Oct 26, 2012 at 2:29 PM, John Case c...@sdf.org wrote: [SNIP] Apparently you think the best way to get a secure platform is to apply pressure through pointless security standards. I'd suggest your efforts might be better spent supplying patches instead. Or, y'know, talking to the authors of the s/w in question. You never know, they might care. Ah, OK. My bad. I've tried supplying patches and filing bug report/enhancement requests. Here was a gentle patch for spelling corrections in a README - rejected. http://rt.openssl.org/Ticket/Display.html?user=guestpass=guestid=2401. Here was a patch for Xcode awareness - rejected (is it fair to say when its sites for years without acknowledgement?). http://rt.openssl.org/Ticket/Display.html?user=guestpass=guestid=2402. I can't locate a bug report on the use of the uninitialized data. Perhaps I had the discussion on the developer's mailing list (I know I'm not imagining it, so my apologies). I am also aware that patches existed for some time for CCM mode, GCM mode, and SRP. In the case of GCM, IBM supplied the patches 5 or 10 years earlier. None were acted upon. The project does not appear to want outside help. If I am drawing the wrong conclusion, please forgive me. Jeff ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Just how bad is OpenSSL ?
Ben Laurie b...@links.org writes: On Tue, Oct 30, 2012 at 11:17 AM, Peter Gutmann pgut...@cs.auckland.ac.nz wrote: Ben Laurie b...@links.org writes: Apparently you think the best way to get a secure platform is to apply pressure through pointless security standards. I think that's a bit of an extreme comment on FIPS 140. For one thing it makes for a great measure of how desperate a vendor is to get onto the US government procurement gravy train, so it does have some value. How can it be a great measure of that when OpenSSL has FIPS 140? It's a perfect measure, it shows how desperate some vendors were to sell OpenSSL (or OpenSSL-using products) to the USG. Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Just how bad is OpenSSL ?
So: 1. What is the process by which you get OpenSSL contributors to notice a serious issue and apply a patch? 2. What are the criteria for applying a patch? Is it just 'whatever interests the devs'? It seems that publishing an exploit works, but is that necessary? 3. It's 2012 -- why the is OpenSSL running its own ticket tracker and source control servers??? (RT is a disaster.) 4. What does it take to become an OpenSSL volunteer? Matt On Oct 30, 2012, at 10:12 AM, Ben Laurie b...@links.org wrote: On Tue, Oct 30, 2012 at 11:58 AM, Jeffrey Walton noloa...@gmail.com wrote: On Tue, Oct 30, 2012 at 5:03 AM, Ben Laurie b...@links.org wrote: On Mon, Oct 29, 2012 at 10:34 PM, Jeffrey Walton noloa...@gmail.com wrote: On Fri, Oct 26, 2012 at 2:29 PM, John Case c...@sdf.org wrote: [SNIP] Apparently you think the best way to get a secure platform is to apply pressure through pointless security standards. I'd suggest your efforts might be better spent supplying patches instead. Or, y'know, talking to the authors of the s/w in question. You never know, they might care. Ah, OK. My bad. I've tried supplying patches and filing bug report/enhancement requests. Here was a gentle patch for spelling corrections in a README - rejected. http://rt.openssl.org/Ticket/Display.html?user=guestpass=guestid=2401. AFAICS that is not rejected, it is ignored. There's a difference. Also, your patch appears to be reversed. Or your spelling is terrible :-) Here was a patch for Xcode awareness - rejected (is it fair to say when its sites for years without acknowledgement?). http://rt.openssl.org/Ticket/Display.html?user=guestpass=guestid=2402. Also not rejected. Now, I agree that having patches ignored isn't so great either, but the problem is: * RT doesn't actually work, the guy who allegedly maintains our infrastructure doesn't, and the team can't agree what to do about it (not that its tried very hard). * OpenSSL is mostly maintained by volunteers, who may not have felt particularly inspired by your patches, or may just have missed them. * When people are paid, they're generally paid to do specific things, not to trawl through RT (if they even could) looking for patches to adopt. I'm sure someone could pay for that if they want to, though. * CVS is a shit tool, too, making it hard to deal with patches - we've even agreed as a team to move off it, but see above about infrastructure :-) I can't locate a bug report on the use of the uninitialized data. Perhaps I had the discussion on the developer's mailing list (I know I'm not imagining it, so my apologies). I am also aware that patches existed for some time for CCM mode, GCM mode, and SRP. In the case of GCM, IBM supplied the patches 5 or 10 years earlier. None were acted upon. It always amuses me when bigcorp pays to have a patch made, but somehow manages to fail to understand that the guy applying the patch has to eat, too. Plus, ISTR the IP situation is none too clear on all of these. This reminds me of the first attempt to FIPSify OpenSSL, where there was zero budget for the developer - just money for test labs and the like (what do you mean you want money to work on it? I thought it was free software!). The project does not appear to want outside help. If I am drawing the wrong conclusion, please forgive me. I'll grant you that your very small patches could be considered help, and it is a little unfortunate they they were ignored, but like I say, RT is a shit tool, at least as implemented at OpenSSL, as is CVS (I notice you didn't supply the needed 4 patches, just a single one) and no-one's paying anyone to pick patches up from it, particularly. The rest of your help appears to be specifying flags you'd like to be used and expecting us to do the work for you. Which I actually might, I find that kind of thing therapeutic, but you get my point. I think the project would welcome help - but it needs to be useful help :-) ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Just how bad is OpenSSL ?
On Tue, Oct 30, 2012 at 2:21 PM, Matthew Green matthewdgr...@gmail.com wrote: So: 1. What is the process by which you get OpenSSL contributors to notice a serious issue and apply a patch? I wouldn't know, I haven't tried :-) In my case, just ask (me, that is, not some mailing list). If the issue is serious, I will likely apply the patch. 2. What are the criteria for applying a patch? Is it just 'whatever interests the devs'? It seems that publishing an exploit works, but is that necessary? I think it can be taken as read that the devs are interested in the security and stability of OpenSSL. 3. It's 2012 -- why the is OpenSSL running its own ticket tracker and source control servers??? (RT is a disaster.) Damn good question. Probably because we don't have a volunteer to move everything somewhere else and keep it running. 4. What does it take to become an OpenSSL volunteer? :-) Like most (good) open source projects: sustained contribution. Matt On Oct 30, 2012, at 10:12 AM, Ben Laurie b...@links.org wrote: On Tue, Oct 30, 2012 at 11:58 AM, Jeffrey Walton noloa...@gmail.com wrote: On Tue, Oct 30, 2012 at 5:03 AM, Ben Laurie b...@links.org wrote: On Mon, Oct 29, 2012 at 10:34 PM, Jeffrey Walton noloa...@gmail.com wrote: On Fri, Oct 26, 2012 at 2:29 PM, John Case c...@sdf.org wrote: [SNIP] Apparently you think the best way to get a secure platform is to apply pressure through pointless security standards. I'd suggest your efforts might be better spent supplying patches instead. Or, y'know, talking to the authors of the s/w in question. You never know, they might care. Ah, OK. My bad. I've tried supplying patches and filing bug report/enhancement requests. Here was a gentle patch for spelling corrections in a README - rejected. http://rt.openssl.org/Ticket/Display.html?user=guestpass=guestid=2401. AFAICS that is not rejected, it is ignored. There's a difference. Also, your patch appears to be reversed. Or your spelling is terrible :-) Here was a patch for Xcode awareness - rejected (is it fair to say when its sites for years without acknowledgement?). http://rt.openssl.org/Ticket/Display.html?user=guestpass=guestid=2402. Also not rejected. Now, I agree that having patches ignored isn't so great either, but the problem is: * RT doesn't actually work, the guy who allegedly maintains our infrastructure doesn't, and the team can't agree what to do about it (not that its tried very hard). * OpenSSL is mostly maintained by volunteers, who may not have felt particularly inspired by your patches, or may just have missed them. * When people are paid, they're generally paid to do specific things, not to trawl through RT (if they even could) looking for patches to adopt. I'm sure someone could pay for that if they want to, though. * CVS is a shit tool, too, making it hard to deal with patches - we've even agreed as a team to move off it, but see above about infrastructure :-) I can't locate a bug report on the use of the uninitialized data. Perhaps I had the discussion on the developer's mailing list (I know I'm not imagining it, so my apologies). I am also aware that patches existed for some time for CCM mode, GCM mode, and SRP. In the case of GCM, IBM supplied the patches 5 or 10 years earlier. None were acted upon. It always amuses me when bigcorp pays to have a patch made, but somehow manages to fail to understand that the guy applying the patch has to eat, too. Plus, ISTR the IP situation is none too clear on all of these. This reminds me of the first attempt to FIPSify OpenSSL, where there was zero budget for the developer - just money for test labs and the like (what do you mean you want money to work on it? I thought it was free software!). The project does not appear to want outside help. If I am drawing the wrong conclusion, please forgive me. I'll grant you that your very small patches could be considered help, and it is a little unfortunate they they were ignored, but like I say, RT is a shit tool, at least as implemented at OpenSSL, as is CVS (I notice you didn't supply the needed 4 patches, just a single one) and no-one's paying anyone to pick patches up from it, particularly. The rest of your help appears to be specifying flags you'd like to be used and expecting us to do the work for you. Which I actually might, I find that kind of thing therapeutic, but you get my point. I think the project would welcome help - but it needs to be useful help :-) ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Just how bad is OpenSSL ?
I strongly suggest you move to git ASAP. It's not hard, though some history can be lost in the move using off-the-shelf conversion tools. (MIT Kerberos recently moved from SVN to git, and before that, from CVS to SVN, and they seem to have done a lot of manual cleanup to avoid some losses of history. You might want to talk to them if this is a problem for you, though, frankly, I think it shouldn't be, after all you can still keep CVS around for archeology...) That would be a great first step towards making contributions easier, since then patches can be posted in the form of git branches, pull requests, and formatted patches e-mailed or attached to RT. And refreshing older patches would be much easier too. Nico -- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Just how bad is OpenSSL ?
On Tue, Oct 30, 2012 at 2:31 PM, Nico Williams n...@cryptonector.com wrote: I strongly suggest you move to git ASAP. It's not hard, though some history can be lost in the move using off-the-shelf conversion tools. (MIT Kerberos recently moved from SVN to git, and before that, from CVS to SVN, and they seem to have done a lot of manual cleanup to avoid some losses of history. You might want to talk to them if this is a problem for you, though, frankly, I think it shouldn't be, after all you can still keep CVS around for archeology...) That would be a great first step towards making contributions easier, since then patches can be posted in the form of git branches, pull requests, and formatted patches e-mailed or attached to RT. And refreshing older patches would be much easier too. This is exactly what we've agreed to do. Well, no particular agreement around RT yet, but the git part. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Just how bad is OpenSSL ?
I would be happy to volunteer to move everything to Github. But it really is really, really easy to do, and the maintenance required is minimal. That or git+redmine or git+JIRA would be my suggestion. On Tue, Oct 30, 2012 at 3:28 PM, Ben Laurie b...@links.org wrote: On Tue, Oct 30, 2012 at 2:21 PM, Matthew Green matthewdgr...@gmail.com wrote: So: 1. What is the process by which you get OpenSSL contributors to notice a serious issue and apply a patch? I wouldn't know, I haven't tried :-) In my case, just ask (me, that is, not some mailing list). If the issue is serious, I will likely apply the patch. 2. What are the criteria for applying a patch? Is it just 'whatever interests the devs'? It seems that publishing an exploit works, but is that necessary? I think it can be taken as read that the devs are interested in the security and stability of OpenSSL. 3. It's 2012 -- why the is OpenSSL running its own ticket tracker and source control servers??? (RT is a disaster.) Damn good question. Probably because we don't have a volunteer to move everything somewhere else and keep it running. 4. What does it take to become an OpenSSL volunteer? :-) Like most (good) open source projects: sustained contribution. Matt On Oct 30, 2012, at 10:12 AM, Ben Laurie b...@links.org wrote: On Tue, Oct 30, 2012 at 11:58 AM, Jeffrey Walton noloa...@gmail.com wrote: On Tue, Oct 30, 2012 at 5:03 AM, Ben Laurie b...@links.org wrote: On Mon, Oct 29, 2012 at 10:34 PM, Jeffrey Walton noloa...@gmail.com wrote: On Fri, Oct 26, 2012 at 2:29 PM, John Case c...@sdf.org wrote: [SNIP] Apparently you think the best way to get a secure platform is to apply pressure through pointless security standards. I'd suggest your efforts might be better spent supplying patches instead. Or, y'know, talking to the authors of the s/w in question. You never know, they might care. Ah, OK. My bad. I've tried supplying patches and filing bug report/enhancement requests. Here was a gentle patch for spelling corrections in a README - rejected. http://rt.openssl.org/Ticket/Display.html?user=guestpass=guestid=2401. AFAICS that is not rejected, it is ignored. There's a difference. Also, your patch appears to be reversed. Or your spelling is terrible :-) Here was a patch for Xcode awareness - rejected (is it fair to say when its sites for years without acknowledgement?). http://rt.openssl.org/Ticket/Display.html?user=guestpass=guestid=2402. Also not rejected. Now, I agree that having patches ignored isn't so great either, but the problem is: * RT doesn't actually work, the guy who allegedly maintains our infrastructure doesn't, and the team can't agree what to do about it (not that its tried very hard). * OpenSSL is mostly maintained by volunteers, who may not have felt particularly inspired by your patches, or may just have missed them. * When people are paid, they're generally paid to do specific things, not to trawl through RT (if they even could) looking for patches to adopt. I'm sure someone could pay for that if they want to, though. * CVS is a shit tool, too, making it hard to deal with patches - we've even agreed as a team to move off it, but see above about infrastructure :-) I can't locate a bug report on the use of the uninitialized data. Perhaps I had the discussion on the developer's mailing list (I know I'm not imagining it, so my apologies). I am also aware that patches existed for some time for CCM mode, GCM mode, and SRP. In the case of GCM, IBM supplied the patches 5 or 10 years earlier. None were acted upon. It always amuses me when bigcorp pays to have a patch made, but somehow manages to fail to understand that the guy applying the patch has to eat, too. Plus, ISTR the IP situation is none too clear on all of these. This reminds me of the first attempt to FIPSify OpenSSL, where there was zero budget for the developer - just money for test labs and the like (what do you mean you want money to work on it? I thought it was free software!). The project does not appear to want outside help. If I am drawing the wrong conclusion, please forgive me. I'll grant you that your very small patches could be considered help, and it is a little unfortunate they they were ignored, but like I say, RT is a shit tool, at least as implemented at OpenSSL, as is CVS (I notice you didn't supply the needed 4 patches, just a single one) and no-one's paying anyone to pick patches up from it, particularly. The rest of your help appears to be specifying flags you'd like to be used and expecting us to do the work for you. Which I actually might, I find that kind of thing therapeutic, but you get my point. I think the project would welcome help - but it needs to be useful help :-) ___ cryptography mailing list
Re: [cryptography] Just how bad is OpenSSL ?
On Tue, Oct 30, 2012 at 2:39 PM, Patrick Mylund Nielsen cryptogra...@patrickmylund.com wrote: I would be happy to volunteer to move everything to Github. But it really is really, really easy to do, and the maintenance required is minimal. That or git+redmine or git+JIRA would be my suggestion. The team has ruled out having the master at github. On Tue, Oct 30, 2012 at 3:28 PM, Ben Laurie b...@links.org wrote: On Tue, Oct 30, 2012 at 2:21 PM, Matthew Green matthewdgr...@gmail.com wrote: So: 1. What is the process by which you get OpenSSL contributors to notice a serious issue and apply a patch? I wouldn't know, I haven't tried :-) In my case, just ask (me, that is, not some mailing list). If the issue is serious, I will likely apply the patch. 2. What are the criteria for applying a patch? Is it just 'whatever interests the devs'? It seems that publishing an exploit works, but is that necessary? I think it can be taken as read that the devs are interested in the security and stability of OpenSSL. 3. It's 2012 -- why the is OpenSSL running its own ticket tracker and source control servers??? (RT is a disaster.) Damn good question. Probably because we don't have a volunteer to move everything somewhere else and keep it running. 4. What does it take to become an OpenSSL volunteer? :-) Like most (good) open source projects: sustained contribution. Matt On Oct 30, 2012, at 10:12 AM, Ben Laurie b...@links.org wrote: On Tue, Oct 30, 2012 at 11:58 AM, Jeffrey Walton noloa...@gmail.com wrote: On Tue, Oct 30, 2012 at 5:03 AM, Ben Laurie b...@links.org wrote: On Mon, Oct 29, 2012 at 10:34 PM, Jeffrey Walton noloa...@gmail.com wrote: On Fri, Oct 26, 2012 at 2:29 PM, John Case c...@sdf.org wrote: [SNIP] Apparently you think the best way to get a secure platform is to apply pressure through pointless security standards. I'd suggest your efforts might be better spent supplying patches instead. Or, y'know, talking to the authors of the s/w in question. You never know, they might care. Ah, OK. My bad. I've tried supplying patches and filing bug report/enhancement requests. Here was a gentle patch for spelling corrections in a README - rejected. http://rt.openssl.org/Ticket/Display.html?user=guestpass=guestid=2401. AFAICS that is not rejected, it is ignored. There's a difference. Also, your patch appears to be reversed. Or your spelling is terrible :-) Here was a patch for Xcode awareness - rejected (is it fair to say when its sites for years without acknowledgement?). http://rt.openssl.org/Ticket/Display.html?user=guestpass=guestid=2402. Also not rejected. Now, I agree that having patches ignored isn't so great either, but the problem is: * RT doesn't actually work, the guy who allegedly maintains our infrastructure doesn't, and the team can't agree what to do about it (not that its tried very hard). * OpenSSL is mostly maintained by volunteers, who may not have felt particularly inspired by your patches, or may just have missed them. * When people are paid, they're generally paid to do specific things, not to trawl through RT (if they even could) looking for patches to adopt. I'm sure someone could pay for that if they want to, though. * CVS is a shit tool, too, making it hard to deal with patches - we've even agreed as a team to move off it, but see above about infrastructure :-) I can't locate a bug report on the use of the uninitialized data. Perhaps I had the discussion on the developer's mailing list (I know I'm not imagining it, so my apologies). I am also aware that patches existed for some time for CCM mode, GCM mode, and SRP. In the case of GCM, IBM supplied the patches 5 or 10 years earlier. None were acted upon. It always amuses me when bigcorp pays to have a patch made, but somehow manages to fail to understand that the guy applying the patch has to eat, too. Plus, ISTR the IP situation is none too clear on all of these. This reminds me of the first attempt to FIPSify OpenSSL, where there was zero budget for the developer - just money for test labs and the like (what do you mean you want money to work on it? I thought it was free software!). The project does not appear to want outside help. If I am drawing the wrong conclusion, please forgive me. I'll grant you that your very small patches could be considered help, and it is a little unfortunate they they were ignored, but like I say, RT is a shit tool, at least as implemented at OpenSSL, as is CVS (I notice you didn't supply the needed 4 patches, just a single one) and no-one's paying anyone to pick patches up from it, particularly. The rest of your help appears to be specifying flags you'd like to be used and expecting us to do the work for you. Which I actually might, I find that kind of thing therapeutic, but you get my point.
Re: [cryptography] Just how bad is OpenSSL ?
Thank god... On Oct 30, 2012 7:50 AM, Ben Laurie b...@links.org wrote: On Tue, Oct 30, 2012 at 2:39 PM, Patrick Mylund Nielsen cryptogra...@patrickmylund.com wrote: I would be happy to volunteer to move everything to Github. But it really is really, really easy to do, and the maintenance required is minimal. That or git+redmine or git+JIRA would be my suggestion. The team has ruled out having the master at github. On Tue, Oct 30, 2012 at 3:28 PM, Ben Laurie b...@links.org wrote: On Tue, Oct 30, 2012 at 2:21 PM, Matthew Green matthewdgr...@gmail.com wrote: So: 1. What is the process by which you get OpenSSL contributors to notice a serious issue and apply a patch? I wouldn't know, I haven't tried :-) In my case, just ask (me, that is, not some mailing list). If the issue is serious, I will likely apply the patch. 2. What are the criteria for applying a patch? Is it just 'whatever interests the devs'? It seems that publishing an exploit works, but is that necessary? I think it can be taken as read that the devs are interested in the security and stability of OpenSSL. 3. It's 2012 -- why the is OpenSSL running its own ticket tracker and source control servers??? (RT is a disaster.) Damn good question. Probably because we don't have a volunteer to move everything somewhere else and keep it running. 4. What does it take to become an OpenSSL volunteer? :-) Like most (good) open source projects: sustained contribution. Matt On Oct 30, 2012, at 10:12 AM, Ben Laurie b...@links.org wrote: On Tue, Oct 30, 2012 at 11:58 AM, Jeffrey Walton noloa...@gmail.com wrote: On Tue, Oct 30, 2012 at 5:03 AM, Ben Laurie b...@links.org wrote: On Mon, Oct 29, 2012 at 10:34 PM, Jeffrey Walton noloa...@gmail.com wrote: On Fri, Oct 26, 2012 at 2:29 PM, John Case c...@sdf.org wrote: [SNIP] Apparently you think the best way to get a secure platform is to apply pressure through pointless security standards. I'd suggest your efforts might be better spent supplying patches instead. Or, y'know, talking to the authors of the s/w in question. You never know, they might care. Ah, OK. My bad. I've tried supplying patches and filing bug report/enhancement requests. Here was a gentle patch for spelling corrections in a README - rejected. http://rt.openssl.org/Ticket/Display.html?user=guestpass=guestid=2401. AFAICS that is not rejected, it is ignored. There's a difference. Also, your patch appears to be reversed. Or your spelling is terrible :-) Here was a patch for Xcode awareness - rejected (is it fair to say when its sites for years without acknowledgement?). http://rt.openssl.org/Ticket/Display.html?user=guestpass=guestid=2402. Also not rejected. Now, I agree that having patches ignored isn't so great either, but the problem is: * RT doesn't actually work, the guy who allegedly maintains our infrastructure doesn't, and the team can't agree what to do about it (not that its tried very hard). * OpenSSL is mostly maintained by volunteers, who may not have felt particularly inspired by your patches, or may just have missed them. * When people are paid, they're generally paid to do specific things, not to trawl through RT (if they even could) looking for patches to adopt. I'm sure someone could pay for that if they want to, though. * CVS is a shit tool, too, making it hard to deal with patches - we've even agreed as a team to move off it, but see above about infrastructure :-) I can't locate a bug report on the use of the uninitialized data. Perhaps I had the discussion on the developer's mailing list (I know I'm not imagining it, so my apologies). I am also aware that patches existed for some time for CCM mode, GCM mode, and SRP. In the case of GCM, IBM supplied the patches 5 or 10 years earlier. None were acted upon. It always amuses me when bigcorp pays to have a patch made, but somehow manages to fail to understand that the guy applying the patch has to eat, too. Plus, ISTR the IP situation is none too clear on all of these. This reminds me of the first attempt to FIPSify OpenSSL, where there was zero budget for the developer - just money for test labs and the like (what do you mean you want money to work on it? I thought it was free software!). The project does not appear to want outside help. If I am drawing the wrong conclusion, please forgive me. I'll grant you that your very small patches could be considered help, and it is a little unfortunate they they were ignored, but like I say, RT is a shit tool, at least as implemented at OpenSSL, as is CVS (I notice you didn't supply the needed 4 patches, just a single one) and no-one's paying anyone to pick patches up from it,
Re: [cryptography] Just how bad is OpenSSL ?
Hopefully somebody's doing some kind of integrity check pre-release no matter where it's hosted... :) In either case, happy to help if it is manhours you need, and I'm sure others on this list are as well. On Tue, Oct 30, 2012 at 3:51 PM, Aaron Grattafiori aa...@digitalinfinity.net wrote: Thank god... On Oct 30, 2012 7:50 AM, Ben Laurie b...@links.org wrote: On Tue, Oct 30, 2012 at 2:39 PM, Patrick Mylund Nielsen cryptogra...@patrickmylund.com wrote: I would be happy to volunteer to move everything to Github. But it really is really, really easy to do, and the maintenance required is minimal. That or git+redmine or git+JIRA would be my suggestion. The team has ruled out having the master at github. On Tue, Oct 30, 2012 at 3:28 PM, Ben Laurie b...@links.org wrote: On Tue, Oct 30, 2012 at 2:21 PM, Matthew Green matthewdgr...@gmail.com wrote: So: 1. What is the process by which you get OpenSSL contributors to notice a serious issue and apply a patch? I wouldn't know, I haven't tried :-) In my case, just ask (me, that is, not some mailing list). If the issue is serious, I will likely apply the patch. 2. What are the criteria for applying a patch? Is it just 'whatever interests the devs'? It seems that publishing an exploit works, but is that necessary? I think it can be taken as read that the devs are interested in the security and stability of OpenSSL. 3. It's 2012 -- why the is OpenSSL running its own ticket tracker and source control servers??? (RT is a disaster.) Damn good question. Probably because we don't have a volunteer to move everything somewhere else and keep it running. 4. What does it take to become an OpenSSL volunteer? :-) Like most (good) open source projects: sustained contribution. Matt On Oct 30, 2012, at 10:12 AM, Ben Laurie b...@links.org wrote: On Tue, Oct 30, 2012 at 11:58 AM, Jeffrey Walton noloa...@gmail.com wrote: On Tue, Oct 30, 2012 at 5:03 AM, Ben Laurie b...@links.org wrote: On Mon, Oct 29, 2012 at 10:34 PM, Jeffrey Walton noloa...@gmail.com wrote: On Fri, Oct 26, 2012 at 2:29 PM, John Case c...@sdf.org wrote: [SNIP] Apparently you think the best way to get a secure platform is to apply pressure through pointless security standards. I'd suggest your efforts might be better spent supplying patches instead. Or, y'know, talking to the authors of the s/w in question. You never know, they might care. Ah, OK. My bad. I've tried supplying patches and filing bug report/enhancement requests. Here was a gentle patch for spelling corrections in a README - rejected. http://rt.openssl.org/Ticket/Display.html?user=guestpass=guestid=2401. AFAICS that is not rejected, it is ignored. There's a difference. Also, your patch appears to be reversed. Or your spelling is terrible :-) Here was a patch for Xcode awareness - rejected (is it fair to say when its sites for years without acknowledgement?). http://rt.openssl.org/Ticket/Display.html?user=guestpass=guestid=2402. Also not rejected. Now, I agree that having patches ignored isn't so great either, but the problem is: * RT doesn't actually work, the guy who allegedly maintains our infrastructure doesn't, and the team can't agree what to do about it (not that its tried very hard). * OpenSSL is mostly maintained by volunteers, who may not have felt particularly inspired by your patches, or may just have missed them. * When people are paid, they're generally paid to do specific things, not to trawl through RT (if they even could) looking for patches to adopt. I'm sure someone could pay for that if they want to, though. * CVS is a shit tool, too, making it hard to deal with patches - we've even agreed as a team to move off it, but see above about infrastructure :-) I can't locate a bug report on the use of the uninitialized data. Perhaps I had the discussion on the developer's mailing list (I know I'm not imagining it, so my apologies). I am also aware that patches existed for some time for CCM mode, GCM mode, and SRP. In the case of GCM, IBM supplied the patches 5 or 10 years earlier. None were acted upon. It always amuses me when bigcorp pays to have a patch made, but somehow manages to fail to understand that the guy applying the patch has to eat, too. Plus, ISTR the IP situation is none too clear on all of these. This reminds me of the first attempt to FIPSify OpenSSL, where there was zero budget for the developer - just money for test labs and the like (what do you mean you want money to work on it? I thought it was free software!). The project does not appear to want outside help. If I am drawing the wrong conclusion, please forgive me. I'll grant you that your very small patches could
Re: [cryptography] Just how bad is OpenSSL ?
Solar Designer wrote: On Tue, Oct 30, 2012 at 11:29:17AM -0400, Thierry Moreau wrote: Isn't memory-space cleanse() isolated from file system specifics except for the swap space? Normally yes, but the swap space may be in a file (rather than a disk partition), or the swap partition may be in a virtual machine, which may reside in a file. Is the SSD technology used for swap state in any of the OS distributions? It depends on how the OS is installed. Plenty of installs have swap on SSD. Assuming that cleanse() as to deal only with L1 CPU cache, L2 CPU cache, main memory, and swap space, I considered a periodical swap space sanitation operation to be useful: add a new swap space partition, remove an existing one, sanitize the removed one (low-level, below file system), put it back into the available set of partitions. I did not experiment in practice. But that partition sanitation strategy ought to be part of an open HSM type of project. What kind of HSM is that where you expect to need swap at all? Just disable swap, unless you're using an OS that can't live without swap. I don't know. The intended HSM is Linux-based with a selected set of software components for its mission: server-side packages that would be on the closed HSM's host are candidates for the open HSM context. Then it's just a matter of the shortest route to finish: route a) secure the swap, route b) monitor software components for maximum memory usage vs physical mem plus make a memory exhaustion fault analysis. Alexander -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, QC, Canada H2M 2A1 Tel. +1-514-385-5691 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Just how bad is OpenSSL ?
On Oct 30, 2012, at 9:11 AM, Thierry Moreau thierry.mor...@connotech.com wrote: Then it's just a matter of the shortest route to finish: route a) secure the swap, route b) monitor software components for maximum memory usage vs physical mem plus make a memory exhaustion fault analysis. Errr, isn't the shortest route c) don't use swap in that system? You are not *forced* to use swap in Linux: I have plenty of Linux instances where it is not turned on. Noting that it is humorous that people are attributing this to bad OpenSSL, not bad understanding of the places where OpenSSL runs --Paul Hoffman ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Your GPU's “Fingerprint” Could Lead to New Security Methods
On Tue, Oct 30, 2012 at 10:08:06AM +0100, Eugen Leitl wrote: In the online world, a World of Warcraft account can be worth serious money. With such an incentive, malware is set to steal your WoW login and password, should you become infected. To protect an account, WoW users have the option of purchasing an authenticator for a minor fee of $6.50. Of course, if you lose the authenticator or if it breaks, poof! goes your game access. Security veterans recognize this as two-factor authentication: a password and a separate, physical security device that the owner must have in their possession. While two-factor authentication can greatly increase your security, it also represents another point of vulnerability because you can always lose the device. Researchers in Europe have come up with an alternative. Instead, your computer's graphics processor unit (GPU) would be the authenticator, identifying a user by tying him to his specific GPU. /snip As someone who used to play WoW extensively and was in games development for quite a while, I wouldn't find this approach desirable either as a player or a developer for this sort of application. What happens when I swap out my GPU for an upgrade? What about players who play on multiple machines, or use their account at a friend's house? If the key supplied by a GPU gets somehow compromised, don't I have to tell the user to buy another? With authenticators I none of these sorts of issues; moreover, I have a clear integration path for incorporating the technology, and a simple, well-defined customer service path - they offer much more of a whole product solution. Taking a step back from WoW and looking at the larger social-mobile trend you see the same sorts of problems; as a user I want secure access from any manner of devices that may change on a frequent basis, and as a developer/operator I want a simple, secure way to manage that. I'm not saying there isn't utility in such an approach as is proposed, only that it seems to me such utility is predicated on an environment where you supply and control the user's hardware and may dictate the user's workflow. An example along these lines would serve better than citing WoW. -Beryl ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Just how bad is OpenSSL ?
On Tue, Oct 30, 2012 at 12:10 PM, Paul Hoffman paul.hoff...@vpnc.org wrote: On Oct 30, 2012, at 9:11 AM, Thierry Moreau thierry.mor...@connotech.com wrote: Then it's just a matter of the shortest route to finish: route a) secure the swap, route b) monitor software components for maximum memory usage vs physical mem plus make a memory exhaustion fault analysis. Errr, isn't the shortest route c) don't use swap in that system? You are not *forced* to use swap in Linux: I have plenty of Linux instances where it is not turned on. Noting that it is humorous that people are attributing this to bad OpenSSL, not bad understanding of the places where OpenSSL runs I'm not sure anyone is blaming negative platform interactions on OpenSSL (I did not get that impression). It is what it is. A comment in the source code on occasion warning about the negative interaction would be nice though. +1 if its properly formatted, too. Jeff ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Your GPU's ???Fingerprint??? Could Lead to New Security Methods
On 30.10.2012 14:30, Natanael wrote: Yeah, this looks like TPM with software protection instead of hardware protection. Rootkits can screw it up. I guess that is why the researchers suggested an on-GPU challenge-response protocol implementation which would not hand out the initial SRAM state directly to any software. Den 30 okt 2012 14:27 skrev Solar Designer so...@openwall.com: This is very curious, but ... On Tue, Oct 30, 2012 at 10:08:06AM +0100, Eugen Leitl wrote: Cloning the actual SRAM state in a GPU is not possible, said Dr. Lange. What we've done so far in our research is reading out this SRAM state. We can of course copy this readout. What we're aiming for is to put an authentication system in place where the GPU never hands over the raw data. Instead the GPU uses it in a challenge-response protocol, just like the secret key in a signature system or zero-knowledge protocol. This does rely on the OS and/or hypervisor shielding the card from bad requests, such as ???hand over all your secrets,??? she said. ... since it relies on OS and/or hypervisor security anyway, about the same functionality and security (not a lot of it) can be achieved by keeping the secret in a disk file (protected with filesystem/OS permissions) and having the crypto implemented in an OS driver (or privileged program). Use of a GPU does not appear to provide much advantage on top of that. It can't be physically cloned, but if OS security fails, then the GPU's secrets can be cloned and the authentication protocol simulated in host software (on attacker's machine, without the GPU). Alexander ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
