SoylentNews is people
SoylentNews
What they've found is that there's a companion memory leak (CVE-2015-5333) and buffer overflow (CVE-2015-5334) in the SSL replacement candidate.
The researchers from Qualys (their notice published here) said they were trying to see if a remote code execution attack is feasible against vulnerabilities they've turned up in OpenSMTPD (which earlier this month hit version 5.7.3).
“Because we could not find one in OpenSMTPD itself, we started to review the malloc()s and free()s of its libraries, and eventually found a memory leak in LibreSSL's OBJ_obj2txt() function; we then realized that this function also contains a buffer overflow (an off-by-one, usually stack-based).”
The memory leak provides a path for an attacker to cause a denial-of-service attack, and also permits triggering of the buffer overflow.
The LibreSSL team has released fixes for OpenBSD.
(Score: 3, Informative) by TheRaven on Tuesday October 20 2015, @08:47AM
Unfortunately, the alternatives aren't great, especially with interop with other code. (I'm discounting C++, and ObjC as they're directly descended from C)
You really should look at C++ again. With C++14, writing memory-safe code is pretty easy, as long as you're disciplined to never use 'new' (always create objects with make_unique() or make_shared()). Importantly, the things that can cause memory safety problems are now syntactically distinct from safe operations. This is even more true with the GSL Owner and similar.
Objective-C has better support for public interfaces that maintain ABI stability (and is also easy to bridge from other high-level languages) and with ARC Objective-C++ now works very nicely (for example, you can put Objective-C objects into C++ collections and have the memory management work correctly). Using C++ internally and Objective-C for the coarse-grained interfaces gives quite a nice way of writing libraries.
sudo mod me up
(Score: 3, Insightful) by NCommander on Tuesday October 20 2015, @12:50PM
This fairly well summarizes why I don't C++ as a good solution: The C++ FQA [yosefk.com]. The language is fundamentally broken and does not prevent these problems in the real world. Plus when using the STL, and smart pointers and such, when something breaks, it can be absolutely close to impossible to debug. I'm not qualified to speak in-depth on ObjC so I won't even try, though my impression is much of the same points below apply. The new class may solve the object leak problem, but it wouldn't avoid the off by one bug that was found in LibreSSL.
Furthermore, unless you're not going to interface with any external libraries, its close to impossible to use smart pointers or smart objects exclusively; too many things use them. Just off the top of my head: BSD sockets requires pointers in and out for send/recv which is an easy off by one bug. Sockets still doesn't have an abstraction in the STL (and don't tell me Boost is a solution). You can't bolt on sane memory protection for an environment that wasn't designed for it, and a language that actively has to support backwards compatibility. Look at how clumsy generics are with Java; a side effect of the all powerful backwards compatibility gods. The STL has had smart pointers for years, auto_ptr was added in C++03 and does essentially the same thing, and has been ignored for mostly the same reason.
The problem is mode worse that C++ libraries also do not define a standard ABI so you're tied to a specific version of a compiler that generated them. This is why if you use Qt or Boost, you have to specify the compiler you're using. So even if you could wrap all your non-safe calls into some sorta abstraction library, you're still stuck in this painful environment that you need to provide versions of that library for each compiler a user may want to use, or have them compile it yourself.
The language is fundamentally broken, and the C++ technical committee keeps trying to plaster around its flaws, in effect making the language even more impossible to understand. For example, can you name the four types of C++ specific casts, and what there difference is? How about when dealing with the case of multiple interhance, what happens if I don't declare virtual on one of my subclasses methods? What happens then. Static have various different meanings depending on where and how you use it.
C at least has the virtue of being somewhat simple, and thus possibly graspable by mere mortal. It's flawed, and badly so, but not to the extent C++ is.
Still always moving
(Score: 2) by TheRaven on Tuesday October 20 2015, @04:46PM
sudo mod me up
(Score: 2) by NCommander on Wednesday October 21 2015, @07:21AM
Can you cite actual examples disproving my claims? I like being proven wrong, but I'm not going to be dissuaded by "its no longer true".
I've had to work with a C++14 codebase as of late, and most of the pain is still there, and a lot of other headaches (templates for one) are still a core part of the language, made worse by the fact that all the new stuff is dependent on templates.
Still always moving