Slashdot Mirror
Theo De Raadt's Small Rant On OpenSSL
New submitter raides (881987) writes "Theo De Raadt has been on a better roll as of late. Since his rant about FreeBSD playing catch up, he has something to say about OpenSSL. It is worth the 5 second read because it is how a few thousand of us feel about the whole thing and the stupidity that caused this panic."
Update: 04/10 15:20 GMT by U L : Reader badger.foo pointed out Ted Unangst (the Ted in the mailing list post) wrote two posts on the issue: "heartbleed vs malloc.conf and "analysis of openssl freelist reuse" for those seeking more detail.
This could get a lot more ugly...
Once upon a time, SSL certificates were signed against a single root certificate, each SSL cert issuer had a single root certificate authority for each of its product lines. Now all corps issue an SSL certificate that is signed against and INTERMEDIATE certificate, which in turn is signed against the root certificate.
What happens if a provider's server has this exploit and the intermediate certificate is compromised? EVERY certificate signed against that intermediate must be revoked. Or put another way, the ENTIRE PRODUCT LINE must be tossed into the garbage and all certs reissued.
So if Verisign or Thawte discover new their intermediate certificate MIGHT have been exploited, would they say anything? The servers implementing those certs are in the hands of a select few - it would be easy to hide the possibility they might have been compromised.
When the foot seeks the place of the head, the line is crossed. Know your place. Keep your place. Be a shoe.
When Slashdot comments become full front page stories? This was already posted a few times as comments in the last OpenSSL post.
How the hell can you read 298 words in 5 seconds?
Years ago the BSD guys added safeguards to malloc and mmap, but they were disabled for all platforms in OpenSSL only because they caused performance problems on some platforms. He finishes by saying that OpenSSL is not developed by a responsible team.
heartbleed vs malloc.conf
and
analysis of openssl freelist reuse. Short articles with a lot of good information.
-- That grumpy BSD guy - http://bsdly.blogspot.com/
So as far as I can tell, his rant is essentially that people should not use custom allocators and instead rely on the general purpose one built into libc because they can add system wide tools there.
I can see the argument for most cases, that is kinda the point of a general purpose allocator, but encryption (esp if you are doing lots of it) really strikes me as a case where you can really benefit from having explicit control over the behavior. I have worked on a number of applications where custom allocators had significant (user facing, not just benchmarks) impacts on performance. Ironically it also meant we were able to do better checking then the general exploit detection kits since we could bake more specific knowledge into the validator.
maybe its time to re-audit all the openssl code
Why OpenSSL is so popular? It has FIPS-certified module, and this becomes important for selling your product to the government.
So what could be done to prevent something like this from happening in the future? People will keep writing bad code, this is unavoidable, but what automated tests could be run to make sure to avoid the worst of it? Someone with direct development experience please educate the rest of us.
So, it's always great fun bashing "obvious" bugs, especially when they have such an impact, but let it be noted that thousands of implementers used openssl to build systems taking the package at face value despite these now "obvious" deficiencies in development process. If you were that concerned about security, they would have done what Google did, and audit the code. There are of course many practical reasons why people can't do that, but regardless, the blame arrow here points both ways.
Forgive my ignorance, but what could someone use as an alternative?
Where can I find Theo De Raadt's "better roll"? I can imagine him being "on a roll", but on a better roll? That must really be something... better.
How about he replies to the questions that the Slashdot community asked him some time ago?
He seems to go out of his way to piss people off ...
De Raadt wrote "OpenSSL is not developed by a responsible team".
On the contrary, I believe it was developed by a responsible team, that unfortunately made an error.
Most everyone have made errors, even if most go unnoticed and are essentially harmless. This one appears different, but I don't think it justifies De Raadt's moronic comment.
That code is almost a text book example of material that is submitted to the Underhanded C contest...
http://en.wikipedia.org/wiki/Underhanded_C_Contest
I'm not a developer and don't know the convention for version numbers but shouldn't they make the rev number of the repaired OpenSSL something more distinctive than adding "g" to the third digit of the new code? Maybe change it to version 2.0.0 or something more obvious.
Linux is far more secure than Windows. Also more reliable, boots faster. Does not spend ten minutes updated when I turn on, or turn off, PC.
Maybe you should take you childish troll somewhere else?
Major numbers are often reserved for things that break backwards compatibility, minor numbers often denote new features, and the patch revision denotes patches.
Personally I would have bumped the patch rev (the third number).
Because who in the world has ever heard of OpenSSH, right?
Pretty good is actually pretty bad.
"it is how a few thousand of us feel about the whole thing"
Then maybe you thousands should stop complaining and start contributing to the project, which is so under-resourced problems like this are pretty much inevitable.
So.. it has come to this
If you've never heard of him, you're not part of any important "tech community". Period.
Of course it runs NetBSD. BTC: 1NT7QvbetmANwaMzhpVL6
That's pretty scathing. I'd hate to be THOSE guys...
In addition, the mitigation countermeasures also prevent memory debuggers like Valgrind from finding the problem (Valgrind find use-before-init for malloc'ed blocks, but not if there is a wrapper in between that re-uses blocks), and may also neutralize code-security scanners like Fortify.
I have to admit that while my original intuition was "screwup", this looks more and more like some parts of the OpenSSL team have been compromised and did things that make this kind of bug far more likely. Like their own insecure memory allocation. Like not requiring time-of-use boundary checks or having any secure coding guidelines in the first place. Like documenting everything badly so potential reviewers get turned away. Like not having working review for patched or a working fuzz-testing set-up (which would have found bug this easily).
After all, the NSA does not have to sabotage FOSS crypto software. They just have to make sure the quality is low enough. The bugs they can exploit will follow. And the current mess is just a plain classic. Do enough things wrong and eventually stuff breaks spectacularly.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
A lot of large performance-sensitive projects implement custom allocators in the form of arenas and freelists. Lots of platforms have a fast malloc implementation these days, but none of them will be as fast as this for the simple reason that the program knows more about its memory usage patterns than any general-purpose allocator ever could.
Not to say I can't understand Theo's point of view -- if he wants maximum security, then a program which bypasses one of his layers in the name of performance might not be the best for him.
On the flip side, the standards have no notion of such security layers and I feel it is perfectly reasonable for a team to not throw away performance in the interests of some platform-specific behavior. This was a bug, pure and simple. There's nothing wrong with using custom allocators. To say that "OpenSSL is not developed by a responsible team" is simply nonsense.
This is not a problem with OpenSSL, or the C Language or the Malloc implementation, this is a problem because everyone is relying on the same black box they do not understand. Because this is "standard" and common practice to use it. The only long term defense against this kind of vulnerability is software (and hardware?) diversity. Software built on custom SSL implementations may have even worse vulnerabilities, but nobody will discover them, and even if they do, it won't affect everyone on this planet. When I read Theo De Raadt, I fear his "solution" may only worsen the problem. We can't have all our secrets protected by the exact same door, no matter how strong the door is, once it's broken...
is not helping!! What would be useful is a list of popular services affected by this issue the BBC is at least making a start here http://www.bbc.co.uk/news/tech...
Build a Man a Fire, and He'll Be Warm for a Day. Set a Man on Fire, and He'll Be Warm for the Rest of His Life.
A lot of large performance-sensitive projects implement custom allocators in the form of arenas and freelists. Lots of platforms have a fast malloc implementation these days, but none of them will be as fast as this for the simple reason that the program knows more about its memory usage patterns than any general-purpose allocator ever could.
This is security software. You don't sacrifice the library's core functionality to make it run a bit faster on the old Celeron 300 running Windows 98.
Well, what you are pointing out is that a CA is a single point of failure -- Something actual security conscious engineers avoid like the plague. What you may not realize is that collectively the entire CA system is compromised by ANY ONE of those single points of failure because any CA can create a cert for ANY domain without the domain owner's permission. See also: The Diginotar Debacle.
The thing is, nobody actually checks the the cert chain, AND there's really no way to do so. How do I know if my email provider switched from Verisign to DigiCert? I don't, and there's no way to find out that's not susceptible to the same MITM attack.
So, let's take a step back for a second. Symmetric stream ciphers need a key. If you have a password as the key then you need to transmit that key back and forth without anyone knowing what it is. You have to transmit the secret, and that's where Public Key Crypto comes in, however it doesn't authenticate the identity of the endpoints, that's what the CA system is supposed to do. Don't you see? All this CA PKI system is just moving the problem of sharing a secret from being the password, to being which cert the endpoint is using -- That becomes the essential "secret" you need to know, and it's far less entropy than a passphrase!
At this time I would like to point out that if we ONLY used public key crypto between an client and server to establish a shared secret upon account creation, then we could use a minor tweak to the existing HTTP Auth Hashed Message Authentication Code (HMAC) proof of knowledge protocol (whereby one endpoint provides a nonce, then the nonce is HMAC'd with the passphrase and the unique-per-session resultant hash provides proof that the endpoints know the same secret without revealing it) to secure all the connections quite simply: Server and client exchange Nonces & available protocols for negotiation, the nonces are concatenated and HMAC'd with the shared secret stored at both ends, then fed to your key-stretching / key expansion system AND THAT KEYS THE SYMMETRIC STREAM CIPHER SIMULTANEOUSLY AT BOTH ENDS so the connection proceeds immediately with the efficient symmetric encryption without any PKI CA system required.
PKI doesn't really authenticate the endpoint, it just obfuscates the fact that it doesn't by going through the motions and pretending to do so. It's a security theater. SSL/TLS and PKI are essentially the Emperor's New Secure Clothes. At least with the shared secret model I mention above, there's just that one-time small window of PK crypto for secret exchange at worst (failing to intercept account creation means no MITM) and at best you would actually have the CHANCE to go exchange your secret key out of band -- Visit your bank in person and exchange the passphrase, etc. then NO MITM could intercept the data. HTTP Auth asks for the password in a native browser dialog BEFORE showing you any page to login (and it could remember the PW in a list, or even generate them via hashing the domain name with a master PW and some salt so you could have one password for the entire Internet). That's how ALL security should work, it ALL relies on a shared secret, so you want the MOST entropic keyspace not the least entropic selection (which CA did they use). If you're typing a password into a form field on a web page, it's ALREADY game over.
Do this: Check the root certs in your browser. For Firefox > Preferences > Advanced > Certificates > View. See that CNNIC one? What about the Hong Kong Post? Those are Known bad actors that your country is probably at cyber war with, and THEY ARE TRUSTED ROOTS IN YOUR FUCKING BROWSER?! Not to mention all the other Russian ones or Turkish, etc. ones that are on the USA's official "enemy" list. Now, ANY of those can pretend to be whatever domain's CA they want, and if your traffic bounces through their neck of the woods they can MITM you and you'll be n
This is security software. You don't sacrifice the library's core functionality to make it run a bit faster on the old Celeron 300 running Windows 98.
malloc's core functionality is to allocate memory. Any security additions are platform-specific and irrelevant.
Wasn't that the guy of the lamest vendor response in 2007? A little less harsh on your comment would be appropriate, mr. Theo.
It doesn't have to be like this. All we need to do is make sure we keep talking.
Theo De Raadt is the king of tinfoil hats, and behind OpenBSD -- a version of BSD designed to be as secure as possible.
wrong
Allocators in this case make no significant difference with regards to severity of the problem.
What is or is not in process free list makes no difference when you can arbitrarily request any block of memory you please.. only slightly effects chance of success when it becomes necessary to shoot in the dark. Lets not forget most OS provided optimized allocators keep freed memory in their heaps for some time as well and may still not throw anything when referenced.
Looking at code for this bug I am amazed any of this garbage was accepted in the first place. There is no effort at all to minimize chance of error with redundant + 3's and 1 + 2's sprinkled everywhere complete with unchecked allocation for good measure.
Suppose I should be glad 1 + 2 = 3 today and they have not used signed integers when dealing with lengths.
... oh dear god ...
Well at least they learned their lesson and have stopped sprinkling redundant and error prone type + length + padding garbage everywhere... see..
and here ..
... oh well .. Looks like plenty of low hanging fruit to be had for anyone with a little spare time.
To say that "OpenSSL is not developed by a responsible team" is simply nonsense.
Unless you look at the code, and notice they are using unvalidated data for......anything. That's a rookie mistake.
"First they came for the slanderers and i said nothing."
As I read his analysis, OpenSSL relies on releasing a buffer, reallocating it, and getting the PREVIOUS contents of that buffer back -- or else it will abort the connection. (Search for the string "On line 1059, we find a call to ssl3_release_read_buffer after we have read the header, which will free the current buffer." in his article referenced by the parent post).
Now, IMO, this goes way beyond sloppy. Releasing a buffer before you're done with it, and relying on a wacky LIFO reallocation scheme giving you back that very same buffer so you can process it, is either 1) an utterly incompetent coding blunder that just happened to work when combined with an utterly terrible, insecure custom allocation scheme, or 2) specifically designed to ensure that this insecure combination is widely deployed to provide a custom-made back door, as it works only with the leaky custom allocator.
If 1), then I must agree with Theo that the OpenSSL team were indeed irresponsible, since at least one of these two cooperating blunders ought to have shown up in a decent security audit of the code, and any decent set of security-oriented coding standards would forbid them both.
If 2), then it was deliberate, and the tinfoil-hat crowd is right for once.
"My strength is as the strength of ten men, for I am wired to the eyeballs on espresso."
No, they're correct.
A compromised flash drive can infect an air-gapped computer (as could a usb keyboard that includes a hidden flash-drive).
I suppose you could argue that connecting a flash drive is breeching the air-gap, but at that point you're coming very close to re-inventing the "if you never turn it on you can't get a virus" level of pointless pedantry.
It seems to me there would be fewer of these reading wrong memory security violations if core OS utilities were re-written in, say, D, or Go, which have GASP! bounds checking, data types, and even memory management built in.
Sure, there might be a bug in the language environment's implementation of one of these things, but if there is, it only has to be found and fixed in one place, and all derivative software will eventually pick up the fix. Oh and the bug will be instantly and universally famous, because a language is so widely used.
Relying on old C code today seems like flying in a 1955 helicopter. Still works like a charm, til it doesn't.
Where are we going and why are we in a handbasket?
If you absolutely need (and can afford) to roll your own, sure, no problem. But I'd say you need to make sure that you do "at least as good" of a job as the standard stuff, in the areas that are relevant to your software. In this case since you are writing a security library, you can't really ignore security additions to malloc etc. as irrelevant. You may want to either test on those specific platforms, or incorporate those additions into your custom built stuff. Because, again, you are writing a security library that's used by half the web. If you don't have the time and / or manpower for that, then essentially you are choosing between performance and security - and you are doing security so the choice should be obvious. The second argument is the rather obvious fact (by now) that memory management has had a significant impact in the general security (or lack thereof) of software. So you can't just dismiss it on the grounds that "it's just memory allocation" because it's not.
When I was dealing with AD Certificate Services, I was told that the root should be disconnected and offline whenever not in use, but WTFDIK.
Also, they didn't need to use OpenBSD's stuff - any standard malloc would have caused OpenSSL to abort the connection in this case, as Ted shows in his blog post.
mod parent up
Let's not miss the opportunity to point a finger of blame at the RFC, which says " to make the extension as versatile as possible, an arbitrary payload and a random padding is preferred, ". https://tools.ietf.org/html/rf... Arbitrary payload and a random padding for a heartbeat instead of a specified sequence of bits? This is very suspicious.
"Mit der Dummheit kaempfen Goetter selbst vergebens." - Schiller
THAT was a 5 second read.
Can't say I'm surprised. OpenSSL is a pile of dung. It's nothing to do with being written in any language, it's just horrible.
There's not even any documentation. I mean, literally, none. Nothing vaguely useful. How do I programmatically load a certificate into the store, along with a chain of related trusted certificates, and then set my requirements (must be in-date, must be validly signed, etc.) and get out a "It's fine" / "Something's not right" response? The only answers I could ever find were to follow published examples and tweak.
And when it comes to working out where in the published examples structure X comes from, or how to convert it to structure Y, you're on your own unless you happen to have picked a comprehensive (and almost certainly not OpenSSL-supplied) example.
It's just that bad. I was writing a pseudo-DRM for a game / Steam-like distribution platform as a hobbyist project. It was literally horrible to even try to self-sign some certificate and then see if it all panned out later from another computer to guarantee integrity. In the end, I had to "imagine" every possible case and find a way to counter it (i.e. client cert expired, client cert invalid, server cert not signed client cert, server cert has bad chain of trust, client cert not signable for that purpose, etc.) - and almost always there was NOTHING to indicate what the recommended way to do it was.
There is no decent OpenSSL documentation at all. Not even a decent overview of the process of checking certificates. It scared me at the time, knowing how important the library is, and it can only lead to bad code.
In the end, I'm quite glad I don't have to program against it for a living. If I did, I'd be seriously looking for something else.
Hey, some of us really are moved by this, but not quite in the way you might expect. It made me realize it's been a long, long time since I gave money to OpenBSD, so I just set up a new recurring donation. Ted Unangst's writeup proves that this was no mere bug; it was sort of like the Challenger investigation, where you see that a major fuckup was pretty much inevitable, because somebody didn't give a fuck. We all make mistakes (mine are horrible too), but the failure to even do basic testing with the OPENSSL_NO_BUF_FREELIST option flipped either way, is not a mere mistake.
I can't trust OpenSSL after this, because I know that beyond the topic of bugs and mistakes, that team gives less than 1.0 fucks.
Yet there are teams out there who do give two fucks, such as the OpenBSD team.
So maybe if I keep throwing money at them, they will keep on generating great code (like openssh, for example) that I'll eventually get to use in my own Linux (not even OpenBSD!) systems. And then some day I won't have to have OpenSSL installed at all. And resources are not OpenSSL's problem, any more than NASA's resources were a problem on January 28, 1986.
Much though I love NSA related conspiracy theories, especially lately, I think "the NSA writes a pile of crap and gives it away for free in the hope it becomes inexplicably popular" is perhaps not the best one available. OpenSSL has been around for a loooong time with virtually no resources put into it, which is one reason it sucks. The other reason being that the original author wrote OpenSSL in order to teach himself C (and it shows).
Recall that SSL was not very widely used up until a few years ago, and it's only in the last 18 months that suddenly every man and his dog wants a secure website. It's not surprising that core libraries that do it are subpar. Even very large companies like Google or Microsoft have typically only had one or two people who really understood and cared about SSL.
Well, true, it could still be plain old incompetence. I am not disputing that. It is pretty gross incompetence in that case though.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
A lot of large performance-sensitive projects implement custom allocators in the form of arenas and freelists. Lots of platforms have a fast malloc implementation these days, but none of them will be as fast as this for the simple reason that the program knows more about its memory usage patterns than any general-purpose allocator ever could.
...
And good lord the results are generally execrable. Doing something stupid like, for example, writing and using OPENSSL_malloc() instead of just malloc() means you can't use plug-in memory debugging/problem-finding tools like Valgrind and Purify. Eliminating the ability to use a whole class of tools that provide a huge amount of testing and validation capability is not what I'd characterize as a smart choice. Just use the normal calls malloc()/free()/etc and change the libraries you link to.
And get over yourself - you're not going to write a memory allocator better than what comes with your OS. If your implementation is faster, it's likely only because you've eliminated the locking implicit in most standard library malloc() implementations.
And even then no memory allocator is faster than using local variables on the stack. Zero performance cost - the stack pointer is incremented anyway. No locking - each thread owns its own stack.
If you know your application's memory usage patterns well enough to be able to write your own memory allocator, you'd probably be better served just using local variables on the stack. Need a big stack? See "man pthread_create". Have fun; learn something.
And if speed is so damn important that system-supplied malloc() and free() aren't fast enough for you and you can't run thread(s) on custom-sized stacks, rethink your damn design. Don't call malloc()/free() or new/delete so many damn times. And remember, it's gonna be a helluva lot cheaper to license something like Hoard than it would be to write your own. Not only cheaper, you won't do it as well, your implementation won't be as fast, and your implementation will definitely be buggier.
But hey, you're a DEVELOPER, and for every nail that's a problem your hammer is to WRITE MORE CODE!!!!
As someone who had to program communication over SSL connection using just C++ and OpenSSL, I'd like to chime in and say -- OpenSSL is a piece of shit. It's API is horrible, error messages/codes are useless and there is no decent instrumentation to investigate (and understand) problems. Not surprised at all that it sucks on implementation level too. The sooner word replace it with a decent library -- the better.
So what is new?
---- Booth was a patriot ----
Is the alleged most secure operating system safe, or just as vulnerable as every other OS?
If you ignore ACs because they are anonymous - you're an idiot.
1. No documentation. None. Nicht. Zero. Nada.
2. Valgrind goes crazy unless you compile OpenSSL with special flags.
3. (subjective) APIs suck
And one reason to use it: Nothing better available.
Both Verisign and Thawte are brands own by Symantec
Test your servers yourself: https://gist.github.com/takesh... This was a server-side attack so clients are unaffected.
In Bitcoins! Then they can hire more dev's and pay them with Bitcoins, new dev's that can help tidy up code that go where it should when there's a problem.
What's your intention with your statement? Or didn't you read the whole lot?
There are a number of angles to it; Theo mentioned one only.
Someone who releases a buffer, and then rereads it, hoping to get the same data commits definitively a very major and unforgivable error. And then plug it into one of the basic security-relevant software without testing is irresponsible.
Any security additions are platform-specific and irrelevant.
Funny, considering that the developers of every major OS would disagree with you, especially after countless bugs and security holes have shown that letting a process have free reign over memory that it does not own (page management, virtual address space), that it never marked as containing executable code (data execution prevention) or that it just told the library that it will no longer touch (undefined behavior) is a really bad idea.
Each of these security features became a necessity after countless C developers repeatedly showed the world that just managing memory was not enough to handle the huge amount of security and trust problems an OS and the programs that run on it have to deal with. Having a security library bypass these necessary extensions under the guise of "lawl we are the uber 1337 C haxx0rs, fuck all those silly access and overflow checks we wanna have speed 111!!!!111!!".
Doesn't affect OpenSSH, because it's openSSL is used for key generation, not SSL in the context of openSSH.
Certificate Authorities who operate on the scale absolutely do NOT keep private keys of the issuing intermediate available for harvest. That's what HSMs are for; devices which hold the private key material and perform signing operations on behalf of the CA. The CA can never retrieve the private key(s) so compromising the CA in that scenario should never result in private key disclosure.
if 2+2=5, then 5=4
Cheap storage VM.
Theo has been a strong proponent of hard hats/steel helmets, not tinfoil hats. Most people thought that approach was overkill for general walking around, at least up until Snowden showed there were lots of national actors firing lots of rocks into the air.
Laissez lire, et laissez danser; ces deux amusements ne feront jamais de mal au monde. - Voltaire
(And there are proof-of-concept worms that can jump the air gap via audio once the initial infection is accomplished.)
Can anyone offer advice on these? Are they just something diferent, or are they significantly better than OpenSSL?
What does OpenBSD use for SSL by default - does it have it's own implementation or is it affected by the OpenSSL bug?
Computers cannot be properly secured.
Ciphers are supposed to be so fucking complex that all implementations will be impossible to do securely.
Our minds have been pwned by some really smart admirals and generals. They often convene in Maryland.
Rip out all the SSL crapola and roll your own minimalist 3DES-based block cipher crypto. It will definitely be more secure against NSA and the Russkie mafia. And the Nork long-range recon forces.
Computors are not supposed to be secure from inspection by the goons of 1%.
...please do all the development and the proofs clandestinely. Post on usenet signed using gpg. Otherwise your great code will soon be "improved" by some people who "join your team" and "make mistakes".
...he would not use C. He merely has some stricter standards in some aspects.
There was this random-source bug with OpenSSL not long ago. I looked at the code then and was horrified.
Now, I do think that TPTB really don't want this kind of thing to be secure. It is obvious that defensively coded C++ would be way more robust and would have a lesser number of bugs.
...have more dollars and more bitcoins.
...the thing opens a capability to folks who have the best minds, lots of money and lots of time at their hands. Say, computer scientists and mathematicians. Not Kayleen F Hacktress of 17 years living in her bedroom in the same house as her partents.
Easy enough for pros, too difficult for the amateurs. Malice or incompetence ?
A) I was blasting M$ in the past; they deserved it. Monopoly, lazy coding, greed,....
B) I am aware of the HPUX ping of death thing
C) By growing older, I also grew much more cynical. FOSS and Unix have serious problems.
Many people have forgotten a cardinal rule of software development:
First you make it right. Then you make it fast.
Implied is, you never sacrifice the former for the latter. Performance is always good but you don't want to start making significant sacrifices on functionality, correctness, code readability, documentation, etc. And, as others here have pointed out, when you subvert the primary purpose and mandate of the software you have created, no matter how that happened, time for a rethink.
OK, so an open-source program that is used by almost EVERYONE had a bug. Who is accountable for this problem? The last programmer that touched the code? The lead programmer? Who?
go back to massively parallel abaci; it's the only solution.
Some time ago, a vulnerability was revealed in OpenSSL, and I guess there's no programmer who hasn't been talking about it since then. I knew that PVS-Studio could not catch the bug leading to this particular vulnerability, so I saw no reason for writing about OpenSSL. Besides, quite a lot of articles have been published on the subject recently. However, I received a pile of e-mails, people wanting to know if PVS-Studio could detect that bug. So I had to give in and write this article: http://www.viva64.com/en/b/025...