Bug-hunt turns up vuln in LibreSSL Code reviewers looking over a mail daemon have turned up a couple of reasonably serious bugs in the Libre SSL code base – and along the way provided a handy illustration of the deep interdependencies between software. What they've found is that there's a companion memory leak (CVE-2015-5333) and buffer overflow (CVE-2015-5334 …
This post has been deleted by its author
LibreSSL was *forked* from OpenSSL, and the team has ripped out half of the code that is obsolete...
I don't think this is a case of humble pie, it is quite possible that OpenSSL suffers from the same (and no-one's tested it). The fact that they are addressing it is a good thing (obviously! They know their reputation depends on it). As opposed to OpenSSL where it usually languishes in a bug system no-one seems to be looking at...
This post has been deleted by its author
>Wasn't this project started because of the lack of trust in OpenSSL?
I think if you compare the number of CVEs between OpenSSL and LibreSSL it will answer your question. There are significantly more CVEs that affect OpenSSL only than affect LibreSSL only even at this point. This even though LibreSSL is forced into using OpenSSL's often broken design and sad sack API to maintain drop in compatible.
It's something of a tradeoff. Enforcing allocation limitations involves some kind of watchdog: entailing a performance and memory penalty to do the deed. The lower level you get, the harder it is to do something like this while also the easier it is to squeeze the most efficiency out of your program. The performance hit may not seem like much in a single instance, but if placed in underpowered hardware or aggregated via virtual computing, they can add up.
If you are using malloc & free then you can run the code using the electric fence library (or similar) that uses the system's VM manager hardware to enforce bound checking and will trigger a segmentation fault and thus a core dump for debugging the code. This has very little performance penalty and requires no code change other than linking with the efance library.
What is much more of a pain is the abuse of stack-allocated arrays as they are much more likely to lead to code injection, and often confuse the debugger if the function context (return address) gets trashed.
Anyone know of a simple way to debug that? I.e. some automated way of using an electric fence style of check on stack arrays without a massive code change?
Also it is worth noting that a number of tools like Coverity are quite pedantic about array use from a static analysis point of view and will help find such problems even before you run the code. Not always of course, but use all the tools you have...
valgrind wants to be your friend! The performance penalty is not very big, but your statement
> ... very little performance penalty
is a bit optimistic, I must say. A handy alias is
alias val='valgrind --tool=memcheck --leak-check=full --show-reachable=yes --error-exitcode=1'
Enjoy!
Thanks for reminding me of valgrind. Yes, it is not quick but it is a useful tool!
My comment about the efecne library is it has some minor performance hit on the allocation/freeing, but once you have an array it is pretty much full speed and not having to check array indexes on every access as the chip's VM unit will alert on out-of-bounds access. How much that impacts on a program depends on the relative amount of malloc'ing versus amount of array access.
>If you are using malloc & free then you can run the code using the electric fence library (or similar) that uses the system's VM manager hardware to enforce bound checking and will trigger a segmentation fault and thus a core dump for debugging the code
AFAIK the MMU can't enforce access at a sub page level so `malloc(77)[128]` could never trigger a page fault. And you're going to flood the TLB if you give every malloc a page.
> ...if you give every malloc a page.
IIRC that's what efence does. valgrind keeps track of data (ranges, reads, and writes) which seems to be a much more sophisticated approach. Note that memcheck is just one instrumentation that valgrind offers.
Once tried to read the fine source code of valgrind. Let's say I did not succeed.
malloc either gives you a pointer to some memory with the size you asked for or not.. I'm not seeing why it would be malloc's fault if you write past the memory you asked for.
If you have the kind of programmer who doesn't think a problem through well enough to ask for the right amount of memory when calling malloc you should perhaps put those programmers onto a project that doesn't manipulate data buffers at a low level; or that uses some language, library or framework that provides a higher-level abstraction of a data buffer that doesn't require raw pointer manipulation.
What we're seeing here is that even quite good programmers make screw-ups when using malloc and free, and that it's high time we stopped using languages that offer nothing safer than malloc and free for memory management.
You need an array of arbitrary byte values (because you're, say, manipulating encoded data or reading a binary network buffer or manipulating memory mapped to hardware or whatever) and you don't like C/C++'s way. So is there an alternative to, say, Java's method which is allocate a fixed-length array but then it's a bureaucratic nightmare to actually get at and set the byte values?
>The joys of malloc and buffer overflows - the gifts that just keep on giving.
And yet Java just moves the CVEs from the code (where the developer has control and responsibility) into the run time itself (where he/she can't and Larry tends to be one of the worst in the industry at fixing his shit). C++11(+) I guess might be more the happy medium the original poster was implying.
It never ends. OpenBSD has some of the most secure, audited code on the planet and a driven team, but they still find issues. When the strict memory allocator became default in OpenBSD a few years ago, it broke twenty year old Unix code that no-one had found errors in before.
Also, yeah, people *do* check processor's code, or at least the output - think back to the Pentium FDIV issue. There have been many processor errata, they're just not covered as extensively. When you're absolutely certain your code is ok, and the compiler is ok, then the only thing left to do is compare your hardware with other hardware to see if the issue remains.
This is working as designed - a fairly obscure issue has been found, it will be fixed, and standard OpenBSD features stopped it being exploitable.
Plus, nowadays x86 CPUs are essentially RISC with a microcode translator on top. One advantage is that if a microcode bug is discovered (a-la FDIV bug), it doesn't render a bunch of CPUs broken. Instead the CPU manufacturer just issues a microcode update, which gets loaded into your CPU at boot, and life goes on as before.
So microcode/CPU errors, are rarely brought to the spotlight as much as before, nowadays people just patch their BIOS or download the new microcode and carry on, some may not even realise that their CPU has been updated.
Yes, truly wonderful, especially once the vendors stop producing updates for older CPUs, but continue to publicize the vulns they would have addressed. Gotta have some reason to ditch your 3 year old system for something shinier. No I don't know of such an event (yet), but plenty of OS instances. BIOS and Microcode cannot be far behind.
And then there is the "upgrade" that actually introduces a vulnerability, perhaps "encouraged" by a patriotic duty to save us all from evil (such as opposition to the current regime).
Actually, thinking about it, perhaps some really really savvy hackers out there could actually make a microcode virus.
I would imagine it as a two part system (as microcode usually is loaded at boot, and wiped at power off), where the OS is infected, loads up the exploit microcode, which then sits and stays resident, making sure any attempts at OS cleanup fail (probably by just re-infecting it every time).
Essentially the two parts will make sure the other cannot be removed, until someone uses a liveCD to break the cycle and wipe the OS (assuming you could detect it in the first place).
I admit this is just out there, because I have no idea how microcode is structured, whether you can actually write programs in there (or is it just a translation table?) and how much space you have (although you can get 16MB cpu cache nowadays, which could fit the whole of win3.1 requirements with memory to spare), but an interesting idea none the less.
This was a vulnerability assessment and pen test. Which eventually found security bugs escaped from LibreSSL reviews and QA. It's surely easier to look at the source code, but you can easily found them in ASM code as well - and if debug symbols are available - match them to their library function names (and note even Windows debug symbols are available, as well as "checked" builds...)
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
