critical vulnerability in devel log4j

mark_j said:
And OpenVMS has its own SSL stuff and doesn't use OpenSSL anyway (though you can use a 'port' of it).
That's why that OS and its 'products' weren't susceptible to heartbleed.
Removing this code makes for a lot less #ifdefs and more readable code.
Click to expand...
There are always more than one points of view to most subjects, here:
  1. LibreSSL and peanut fans are are already annoyed -- I can’t care less

  2. From an application programmer’s point of view, it is a unique selling point of OpenSSL when it comes to targeting more than one OS. I target FreeBSD and macOS using OpenSSL, and on this side without any #ifdefs. macOS comes also with it’s own TLS stuff, and so I guess this might become subject of a future rant of Theo. I won’t held my breath, since with OpenSSL, I can’t care less.

  3. From the OS maintainers point of view, you want to reduce the maintenance efforts, of course. Now FreeBSD choose not to implement its own TLS stuff, but rely on third party contributions. From the FreeBSD point of view it doesn’t matter, whether OpenSSL supports OS/2 and VMS, and tons of others as well, as long as it works fine with FreeBSD. And anyway it got „Free“ in the name, so users are yet free to use other stuff to their liking.

  4. Now, the user's point of view is not my problem, and I am usually very hesitant to let others making their problems with some stuff to be mine.
PS: As long as you target big endian systems anyway, like e.g. the Power architecture, from a maintenance point of view it doesn’t matter if you add a few more to the list of big endian’s. I know what I am talking about, since some of my software have roots when Mac OS X came with big endian PowerPC’s, and I got a lot of electrochemical measurement files, where data values were stored in the natural big endian sequence and which can be still processed by the latest versions of my software. Natural, because for example a 128bit PPC long double appears in the hex editor in the natural reading from left to right. Anyway, all the endianes stuff can be handled almost transparently to the rest of the application by one well designed include file.
 
Me posting about the issues with OpenSSL that surfaced was in the context of having to do even more updates besides the already huge mountain of work due to the log4j issue. It wasn't an incentive to discuss the pros and cons of LibreSSL vs. OpenSSL.
 
Kristian Köhntopp, a well renowned computer scientiest and author in Germany, wrote a comment about the log4j issue on Heise Online. It can be found here, it's in German only: https://www.heise.de/meinung/Kommentar-zu-log4j-Es-funktioniert-wie-spezifiziert-6294476.html

Köhntopp argues that the exploit is not a bug, because what's being exploited here is Java working as specified: loading code fragments during runtime from places all over the globe, and putting them together. He also mentions that there was a piece in Oracle Java available called Oracle SM for Security Manager, whose sole purpose was to restrict from where pulling code was allowed. Since nobody wanted it, it became deprecated though in Java 17 and will be later removed somewhere.

So to sum it up: Java is doing what it is intended to do. Aside that it's a big, fat cluster fuck.
 
Can you link the article? Doesn't matter if it's in German, those of us who cannot read German can use a translator to read it. The more information we have the better.
 
Being a fan or not has nothing to do with it. The fact is Libressl has had far fewer known vulnerabilities than Openssl, yet support for the former is waning across all platforms except Openbsd. Having basically the entire open source ecosystem depend on a single cryptography library is dangerous, just like PHK warned. He was prescient, but seven years later here we are once again depending almost exclusively on a single library that keeps having problems.

There's no indication that "Theo" or anyone else plans to drop support for Mac OS in Libressl portable. Or that anyone is recommending that support for any of the big-endian platforms they support be dropped. Suggesting such is purely spreading FUD.

I thought that big-endian x86 would be obviously obscene, but I guess I'll have to spell it out. There never was such a thing. All Intel x86 chips and their clones were and are little-endian. This bizarro-land "platform" was added to Openssl because someone paid the for-profit company that owns the copyrights and maintains the code to add it. I don't want to be saddled with the oodles of code and latent bugs that can be added by this process.

Moderators: It would be cool with me to move the Open/Libressl posts to this thread if you like:
forums.freebsd.org

Slouching towards a cryptography monoculture

I'm saddened and disappointed by the current trend of jettisoning support for Libressl. https://voidlinux.org/news/2021/02/OpenSSL.html https://www.gentoo.org/support/news-items/2021-01-05-libressl-support-discontinued.html https://www.python.org/dev/peps/pep-0644/#libressl-support I'm puzzled...
forums.freebsd.org forums.freebsd.org
 
Anyway, there's a new CVE-2021-45046 that was previously though of as only a DoS (in some databases, still shows as a low "score") but is actually an RCE (higher score) and now updating to 2.16.0 that removes the patterns and removes JNDI by default is the solution.

So if you updated, time to do it again.
 
Jose said:
Being a fan or not has nothing to do with it. The fact is Libressl has had far fewer known vulnerabilities than Openssl, yet support for the former is waning across all platforms except Openbsd. Having basically the entire open source ecosystem depend on a single cryptography library is dangerous, just like PHK warned. He was prescient, but seven years later here we are once again depending almost exclusively on a single library that keeps having problems.
Click to expand...
There are still enough alternatives to OpenSSL around. What happened is that

a) LibreSSL never really delivered up to its promises aside security claims,
b) OpenSSL in the mean time catched up on speed, as well as new features and
c) LibreSSL is slow on adopting new features, if all it lags behind OpenSSL in that regard, which makes it not really a dropin replacement as promised in the beginning,
d) speed: LibreSSL has nowadays the reputation of being much slower than OpenSSL.

Also in general there are not many developers around with the knowledge to work on cryptographical libraries, since the smallest deviation from the algorithm might cause big trouble. This is why this special area of programming itself already has quite a small pool of potential developers per se, making the one thing to rule them all stuff even more likely to happen.
 
Really should take this to a different thread, but whatever.
hardworkingnewbie said:
a) LibreSSL never really delivered up to its promises aside security claims,
Click to expand...
What promises did it not deliver on?

hardworkingnewbie said:
b) OpenSSL in the mean time catched up on speed, as well as new features and
Click to expand...
Libressl added new cipher suites not available in Openssl in its very first release.

hardworkingnewbie said:
c) LibreSSL is slow on adopting new features, if all it lags behind OpenSSL in that regard, which makes it not really a dropin replacement as promised in the beginning,
Click to expand...
The Openssl project has taken to implementing draft standards. I question the wisdom of doing such in critical cryptographic software.
github.com

Add support for TLS 1.3 · Issue #228 · libressl/portable

Will LibreSSL wait for OpenSSL to add TLS 1.3 support? openssl/openssl#963
github.com github.com

The Heartbleed bug was introduced in a poor implementation of a "heartbeats" feature nobody used. The fix was simple. The feature was removed and no one missed it. More code means more bugs. I prefer Libressl's conservative approach:
(W)e find empirical evidence that larger code changes produce more vulnerabilities. In OpenSSL specifically, we find a lower bound of 1 vulnerability introduced for every thousand lines of code. Our case study of the LibreSSL and BoringSSL forks further demonstrates a linear correspondence between source code removal and vulnerability removal. Our findings support the common intuition that it is dangerous to maintain excess amounts of C or C++ source code, and particularly so in cryptographic software.
Click to expand...

hardworkingnewbie said:
Also in general there are not many developers around with the knowledge to work on cryptographical libraries, since the smallest deviation from the algorithm might cause big trouble. This is why this special area of programming itself already has quite a small pool of potential developers per se, making the one thing to rule them all stuff even more likely to happen.
Click to expand...
This is a common talking point used to whine about how hard it is to support Libressl. You don't have to be a cryptography expert to use either Openssl or Libressl. The crypto implementations are written by cryptographers, and are isolated from the standard library API code.
 
Hi, there's a third Log4J CVE-2021-45105 and patched version 2.17.0 due to insufficient recursive protection. Also there's a worm out now.

Roughly 20% of the posts in here belong in off topic. Good work everyone. :rolleyes:
 
msplsh said:
Hi, there's a third Log4J CVE-2021-45105 and patched version 2.17.0 due to insufficient recursive protection. Also there's a worm out now.
Click to expand...
Not surprised. They decided loading code over the network and executing it was a good idea. Chances the rest of the code is crap are high. Besides, they're in crisis mode now. I expect another 2-3 versions by the end of the week.

Some good may come of this. Hopefully people will look at Logback if they really need fancy logging, and just use Java Logging otherwise.

Apache Log4j deserves to die a horrible death.
 
People have added the magic string to the name of their iShiny, only to see access attempts from the apple IP range. This is getting bizzare.
 
You must log in or register to reply here.
Back
Top