OpenSSL preps fix for mystery high severity hole The OpenSSL Project will repair a "high severity" security hole in updates due Thursday. Information is thin on the ground. El Reg has asked OpenSSL for more details to help admins prepare for the patching. The hole will be patched as part of a series of fixes that will land on 19 March and apply to versions 1.0.2a, 1.0.1m, 1 …
Why do you think they're delaying the official release of the fix?
No one is "delaying the official release". The OpenSSL team initially announced it would be released on the 19th, and that's what they're still saying. For the past few releases it's been their policy to announce an upcoming release at least a few days before it's available, so that people can get ready to adopt it.
This post has been deleted by its author
Exactly. And when you use stuff like Java, bugs (and security flaws of course) are a built-in feature, but unlike in C there's sod all the developer can do about it.
The problem ----> XXXX
Your head -------> o .... "waaah stop liking Java, it's shit!!"
Writing complex code in C in 2015 is quackery and incompetence. Or a manifestation of ego problems. Deal with it.
"Writing complex code in C in 2015 is quackery and incompetence. Or a manifestation of ego problems. Deal with it"
It's so very simple, that Linux kernel... Same for that Windows kernel, and FreeBSD. Not complex in any way at all. And I suppose the libraries and run times for all your high level languages are written in C/C++ too, so they must be simple also.
What a berk you are.
Some of the most complex code on the planet has to be written in C. The clever people have to provide them to idiots like you so that you can get some work done without making a gazillion mistakes.
Complex code doesn't *have* to be written in C, this, for example is one of many complex operating systems written in Pascal:
http://en.wikipedia.org/wiki/VAXELN
Most code is written in C because (a) it's familiar to developers and (b) there are compilers for most platforms (because it's not hard to compile). A long time ago, I had the misfortune to work with naval architects writing software to design ships. The same argument was made then about FORTRAN.
C is just an accident waiting to happen when it comes to dealing with, for example, ASN.1 encodings.
Even though C is not my favourite language, I refuse to bash it on the basis of "being old" or ill-suited or something. Its strength is simplicity of design, and while personally I like (or even, demand) more refined languages to manage coupling and complexity of my own software projects, I am full of awe to those who manage to make very complex projects without such language features, in C. Linux kernel and GCC are two examples of such projects.
OpenSSL? Not so much, it was borked from the very beginning by the attitude of its developers "lets keep all features and platforms in, ignore all the standards and instead code all basic platform features ourself, no matter how irrelevant or possibly harmful it could be in the future" - but this has nothing to do with language and everything to do with culture. While each language comes with its own culture (set of idioms, support for certain design paradigms, approach to software design etc) there is nothing in C that would dictate such broken design - quite the opposite, actually. It's simple language that can be best characterised as "more elegant weapon for a more civilized age" but, like any weapon, it can be misused.
You can write crap code in any language, yep. I worry more about PHP, SQL injection, and XSS than I do about OpenSSL. Of course that's because I don't pretend it's possible to build secure websites.
To be fair, I see tons of security patches coming through for C libs used in web servers/browsers; those concern me. It's too bad that C didn't evolve a bit further before becoming the de facto standard systems language.
You seem to forget that C was largely created to be a systems language in order to write UNIX in the 70s. Do you really think an OS written in assembler would be a better idea?
Of course, the other side of a "systems" tool is it lets you do things that might not be smart, even though you might just need to that sort of thing inside an OS. Common mistakes relate to memory usage (not bound-checking, use after freeing, etc) and the notorious printf()-like calls that can really mess things up on the same basis (it relies on you telling it correctly what type of arguments are being passed).
Wile other languages take away your ability to make some of those mistakes, much of those problems are now managable if only folk would use the C-language tools that are already out there! Static analysis tools (e.g. Coverity) and using maximum warnings from your compiler (gcc can now check printf formats, and please us snprintf() to force memory length restrictions) will help if you are willing to take the time to check what they are squaking about, and fix it.
<shudder>
The point is, though, that it was written by Dave Cutler (of VMS and NT fame) and it was done specifically because they had tight deadlines and didn't want to waste their time on avoidable bugs caused by buffer overflows and careless dereferencing.
I can't help feeling a little less concern for the last fractional percent of performance could have saved millions of collective hours of misery if the same principles had been applied to Windows NT.
The point is, though, that it was written [in Pascal] by Dave Cutler (of VMS and NT fame) and it was done specifically because they had tight deadlines and didn't want to waste their time on avoidable bugs caused by buffer overflows and careless dereferencing.
Still a horrible language, though. Designed as a teaching tool that encouraged people to write 'good' code (according to Wirth) by making it impossible to write 'bad' code. Fine if your IO was limited to
writeln("Hello World");
but for any systems-level programming it was a nightmare. Each implementation had it's own, different, set of extensions for hacking the system which made it just as easy to screw up as with C pointers, but forced you to jump through unnecessary hoops to get there. Modula 2 was better.
<quote>
I can't help feeling a little less concern for the last fractional percent of performance could have saved millions of collective hours of misery if the same principles had been applied to Windows NT.
</quote>
From my experience, software written in "higher" level languages suffers from the same crappiness and malfunctions equally the same. It might not be a buffer overflow, but human idiocy will always find a way around.
Warm Braw said: "this, for example is one of many complex operating systems written in Pascal"
UCSD P-System was also mainly written in Pascal. It saw commercial use in the 1980s and into the 1990s. I worked with a system which used it running on a 68000.
"Most code is written in C because:"
And (c) because it links easily to other software written in C. If you wish to write a library which is intended to be used by other software, C is the lingua franca which links to just about anything without a lot of faffing around.
UCSD P-System was also mainly written in Pascal. It saw commercial use in the 1980s and into the 1990s. I worked with a system which used it running on a 68000.
I suffered with it on an Apple II, although IIRC it ran on the Z80 coprocessor card, not the native 6502. It had an implementation of Fortran as well, which violated the data type rules in the standard and so made anything with COMMON blocks tricky to port. Ah, the yoof of today doesn't know how good they have it :)
Worthy of a Youtube comment. Congratulations sir - you've demonstrated a complete lack of knowledge of an issue; compounded this with assumptions, and for the finisher used a baseless generalisation. Go and ask an adult how much "complex code" is written in C in 2015.
If that guy is so opposed to C, he should maybe try removing all the software written in C from his devices and see how far he gets. (Hint: that would include *all* modern operating systems. Most current "smart" devices, computers, routers, washing machines, medical devices, planes and even cars would be rendered into dumb bricks without C-based software)
C may be old (or rather mature), but short of assembler, outperforms all other languages (most of which use compilers written in C anyway, go figure). This is one of the reasons why it is still very relevant, and will be for some time to come. There's simply no valid alternative for writing code close to the machine layer or for anything where performance really matters.
Also, don't blame the language for a rotten library! OpenSSL is ancient and unmaintainable, and that has been known for almost as long as it's been out there; very long! Nobody dared touching it, because it's so widely used. (Kudos to the LibreSSL guys for attempting to clean up the mess!)
Edit: Disclaimer - I'm not a C developer, but I can recognise its importance and reason d'etre. Common sense and obvious facts beat bias and preferences.
"All other languages" may be an ocean too far.
Yes. It's simply not factually correct that "C outperforms all other languages". That's not even a meaningful statement in any strict or broad sense, and in many specific, practical cases, C's rather loose guarantees1 and lack of expressiveness make it harder for the implementation to use many optimizations. That means such optimization is left to the programmer, and that's rarely a Good Thing.2
I still do most of my work in C, but I'm able to see it for what it is, with advantages (a small specification, few black boxes, widely available) and disadvantages (little existing infrastructure, tempting pitfalls for the lazy, relative lack of expressiveness, etc). History has shown that the advantages of C are often exaggerated by its proponents - just as with most things - and that few programmers are willing to do the work required to write good C code.
1Relatively newer features like the restrict type-qualifier help a bit with this, but only a bit. And restrict is rarely used by C programmers, even though it's been part of the standard for fifteen years. Hell, few C programmers use the const type-qualifier correctly, and we've had it for a quarter of a century.
2Bjarne Stroustrop - with whom I definitely do not always agree, but he makes some good arguments - has a nice example of this involving qsort versus sorting with C++ generics.
After seeing some of Chuck Moore's work, I'd say he makes a compelling argument that Forth can have better performance.
No, Forth doesn't out-perform C except in a few (generally contrived) situations. This is why the two primary Forth systems on the market today[1] are compilers in just the same way as a C is.
Where Forth really does score is in code density; it tends to be heavily-factored from the outset, and words will requently be refactored as a maintenance exercise - code complexity tends to increase rapdily as word size grows.
Vic.
[1] MPE and Forth Inc.
Disclosure: I used to work for one of the above...
These things happen only because almost everyone is quite prepared to believe that a piece of software must be ok if everyone else is using it too. Almost everyone is too busy/lazy/ill equipped to actually check code they're borrowing.
That places a heavy burden on the designers and implementers of software. There are things out there that can help.
For instance there have been decent schema languages for defining interfaces since the early 1990s, e.g. ASN.1 schemas, and now JSON schemas. With the right tools it is very easy to define and implement an interface whilst making that interface very resilient to abuse. Any residual problems tend to be in the schema tools and libraries, which at least are a fix-once-fix-everywhere thing. How many buffer overrun bugs have we had? Lots. Yet they would not have happened at all had a schema and tools been used instead of hand written code.
In case anyone is interested my view on a reliable schema language is that it must be:
1) Typed. Messages define what message type they are
2) Size constrained. Arrays limited in length, checking enforced
3) Value constrained. Variables limited in value to a defined range, checked.
4) Extendible. Allow old code to handle newer versions of a message.
5) Choice of binary and text wire formats. Supports all needs
6) Support many languages (C, C++, Java, etc). It's a multi platform world.
ASN.1 and the associated tools does all of this, JSON Schema does all of them too I think (BSON comes to the rescue for 5?). Google Protocol Buffers does only 4 and 6, does 1 badly, same for Thrift I think.
But where is the fun in that. Coders love their half baked poorly crafted code since they made it. Try telling a Dev he's made a coding error based on the evidence of its behaviour and watch them all kick off. Precious prima donnas with an over inflated sense of their own capabilities. Google Dunning Kruger effect.
"Coders love their half baked poorly crafted code since they made it. "
Well, I think it is worse than that as far as openssl goes:
- they indeed love the undecipherable crap openssl coding is, love the inconsistent API you can short-circuit at will
- none of them understand all parts of the lib
- since it can compile on platforms long gone 25 years ago, no-one touches low-level parts by fear of disrupting WIN16 support, DOS 4 or Ultrix
Another symptom of openssl being out of control is the versioning. 1.02a, 1.02m, 0.9.8zf, seriously, WTF ?
Another symptom of openssl being out of control is the versioning. 1.02a, 1.02m, 0.9.8zf, seriously, WTF ?
Well, since none of those are OpenSSL versions, it seems unlikely the F in question has anything to do with it.
OpenSSL versions are pretty straightforward. They're not ideal, but they're not hard to understand. The numeric triple indicates the version of the OpenSSL API; the letter is the fix level.
Code reorganization and refactoring between the 0.9.8, 1.0.1, and 1.0.2 versions make them source-incompatible at a low level - particularly for people who have their own custom patch sets, which is not unknown. Moving applications from one release to another is generally straightforward, as long as they use the official APIs.
This post has been deleted by its author
I wonder if this is related to the following announcement made to the BugTraq mailing list last week ?
http://seclists.org/bugtraq/2015/Mar/48
During a source-code audit of the OpenSSL v1.0.2 implementation for Linux; conducted internally by the Advanced Information Security Group, instances of deprecated function use, were observed in relation to the GHOST vulnerability (CVE-2015-0235).
If it is, then there shouldn't be anything to worry about if you've patched glibc...
Most of the information about this OpenSSL release is still embargoed, but Nicholas Lemonias posted to BUGTRAQ today about another DTLS bug - a memcpy buffer overrun. The DTLS implementation was also the source of Heartbleed, of course.
Lemonias' message also refers to "deprecated functions", but that's a load of crap. The C standard does not deprecate memcpy. In fact, the only things ISO 9899-1999 deprecates are the use of "argument" as a synonym for "parameter", and the use of ungetc at the beginning of a binary file. And the latter is in a non-normative annex.
9899:2011 replaces gets with gets_s, but doesn't actually deprecate gets (contra Wikipedia). It adds a bounds-checked API, including memcpy_s (in a normative annex), but does not deprecate memcpy. And I see very little C11 code being written anyway, in part because some implementations are still C99 (and not always that; Microsoft still doesn't have a conforming snprintf, for example).
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
