Actually, I think that reinforces my point. I spend most of my day working with security systems (see here) and so I absolutely know better than to send mail without checking the response line and yet I made that sort of boneheaded mistake anyway. This is exactly why software is riddled with bugs and why it seems unlikely we'll be able to patch them out of existence--people make mistakes.
I'm measuring the rate at which bugs are found in single program/version pairs. I.e. are we finding an appreciable fraction of the bugs in Window NT 4.0? So, the rate at which (say) MS introduces new bugs in new versions of Windows doesn't affect this measurement.
I'd make the point a little more subtly: The currently extant programs are riddled with bugs and I don't think the data supports the claim that we're making much progress in finding those bugs.
Now, the argument that you're making is (roughly) that the constant exposure of bugs will incentivize vendors to use more secure software techniques. That's certainly a possibility--though I'm skeptical. However, if the primary goal of finding bugs is to provide these incentives to vendors, then maybe there's some way to do it without the collateral damage caused by publicizing the bugs.
It's true that ephemeral RSA is limited to 512 bits, but DH is not and SSL offers RSA/DH modes. If you look at the performance section of SSL and TLS, you can see that if you use a short DH exponent AND amortize the DH share over multiple connections, you can achieve ephemeral DH performance that is comparable to what you would achieve with ephemeral RSA and 1024 bit keys. Of course, this is still slower than static RSA, but that's the price you pay for doing two computations. Note that it's absolutely critical to use Sophie-Germaine primes if you're going to use this optimization, since otherwise you're open to small subgroup attacks.
Eric Rescorla
Re:methodology in paper is flawed
on
Due Diligence?
·
· Score: 1
This is roughly what I did. Section 4.2 describes how to remotely and harmlessly detect whether patches have been applied.
How sure are you the the administrators of the servers you sampled are also Slashdot readers?
I'm not, but this bug got extremely wide coverage, including writeups on CNET. That said, I think this kind of misses the point, which is that for whatever reason a large number of machines don't get upgraded even following the release of extremely serious security flaws.
Re:FreeBSD binary updates
on
Due Diligence?
·
· Score: 1
Hmm... Do the.so-s install in/usr/lib? If not, then it's still possible that you won't completely displace the existing shared libraries. With the port you needed to specify OVERWRITE_BASE to get this to happen.
Re:When to Patch
on
Due Diligence?
·
· Score: 2, Interesting
Indeed. In fact, I cite your paper in mine.:)
Interestingly, if you look at the curves of people's behavior, you can see that the algorithm they're apparently following is pretty different from the one you recommend. Namely, people who are going to upgrade do so pretty much right away (mostly within 10-14 days of the stimulus that seems to have forced them to upgrade). The second interesting observation is that a substantial number of people seem to wait for a vulnerability to be released before they upgrade. One question that would be interesting to ask in the context of best practices would be how long on average vulnerabilities circulate before they are announced.
Slashdot Mirror
Actually, I think that reinforces my point. I spend most of my day working with security systems (see here) and so I absolutely know better than to send mail without checking the response line and yet I made that sort of boneheaded mistake anyway. This is exactly why software is riddled with bugs and why it seems unlikely we'll be able to patch them out of existence--people make mistakes.
You've misread the paper.
I'm measuring the rate at which bugs are found in single program/version pairs. I.e. are we finding an appreciable fraction of the bugs in Window NT 4.0? So, the rate at which (say) MS introduces new bugs in new versions of Windows doesn't affect this measurement.
I'd make the point a little more subtly: The currently extant programs are riddled with bugs and I don't think the data supports the claim that we're making much progress in finding those bugs.
Now, the argument that you're making is (roughly) that the constant exposure of bugs will incentivize vendors to use more secure software techniques. That's certainly a possibility--though I'm skeptical. However, if the primary goal of finding bugs is to provide these incentives to vendors, then maybe there's some way to do it without the collateral damage caused by publicizing the bugs.
Dan,
It's true that ephemeral RSA is limited to 512 bits, but DH is not and SSL offers RSA/DH modes. If you look at the performance section of SSL and TLS, you can see that if you use a short DH exponent AND amortize the DH share over multiple connections, you can achieve ephemeral DH performance that is comparable to what you would achieve with ephemeral RSA and 1024 bit keys. Of course, this is still slower than static RSA, but that's the price you pay for doing two computations. Note that it's absolutely critical to use Sophie-Germaine primes if you're going to use this optimization, since otherwise you're open to small subgroup attacks.
Eric Rescorla
This is roughly what I did. Section 4.2 describes how to remotely and harmlessly detect whether patches have been applied.
How sure are you the the administrators of the servers you sampled are also Slashdot readers?
I'm not, but this bug got extremely wide coverage, including writeups on CNET.
That said, I think this kind of misses the point, which is that for whatever reason a large number of machines don't get upgraded even following the release of extremely serious security flaws.
Hmm... Do the .so-s install in /usr/lib? If not, then it's still possible that you won't completely displace the existing shared libraries. With the port you needed to specify OVERWRITE_BASE to get this to happen.
Indeed. In fact, I cite your paper in mine. :)
Interestingly, if you look at the curves of people's behavior, you can see that the algorithm they're apparently following is pretty different from the one you recommend. Namely, people who are going to upgrade do so pretty much right away (mostly within 10-14 days of the stimulus that seems to have forced them to upgrade). The second interesting observation is that a substantial number of people seem to wait for a vulnerability to be released before they upgrade. One question that would be interesting to ask in the context of best practices would be how long on average vulnerabilities circulate before they are announced.