Patch AGAIN: OpenSSL security fixes now need their own security fixes

Sysadmins and devs, fresh from a weekend spoiled by last week's OpenSSL emergency patch, have another emergency patch to install. One of last week's fixes, for CVE-2016-6307, created CVE-2016-6309, a dangling pointer security vulnerability. As the fresh advisory states: “The patch applied to address CVE-2016-6307 resulted in …

[Anonymous Coward]

Working hard to beat Adobe?

I'm sure another Flash patch with 50 fixes will come out to put it back on top!

[Crazy Operations Guy]

Burn it to the ground and start over

The code has aged far too badly and the patches upon patches are only going to make things worse. They need to just toss all the code and start over fresh. I assume that this bug stems from the fact that they keep using their hand-built malloc / memory management libraries rather than just using the one built into the OS.

I've switched as many of my machines as possible to follow the LibreSSL fork, but even with the OpenBSD/OpenSSH folk working on it, there will always be bugs hidden waiting to bite us all right square in the ass...

[Mike Shepherd]

Re: Burn it to the ground and start over

"The code has aged far too badly"

Everything ends up a hack. Poor code starts off as a hack. Good code attracts so much demand for new features that it ends up a hack.

[Anonymous Coward]

Re: Burn it to the ground and start over

The entire SSL protocol is a hack. It was doomed from the moment Netscape threw it together at the last minute before the initial release of their browser for marketing reasons ("secure e-commerce"). The developers didn't expect anyone to actually use this crap.

[Anonymous Coward]

And LibreSSL isn't even an option on 32-bit Linux

It's a damned shame that the most recent versions of LibreSSL (2.3.1 to be specific) only work on 64-bit Linux systems, as it actually means OpenSSL is the only viable option on 32-bit Linux if you have to verify CAs expiring after 2038.

https://github.com/libressl-portable/portable/issues/207

LibreSSL have no plans to address the 2038 issue on platforms conforming to the 32-bit Linux ABI, and Linux certainly won't be changing it's 32-bit ABI any time soon (*BSD supports 64-bit time_t, so they're alright jack) but after suckering in the Linux users the LibreSSL developers have now shown their true colours and started acting like total douche bags.

[Dan 55]

Re: And LibreSSL isn't even an option on 32-bit Linux

They decided that if there's a platform problem it's better to fix the platform than work around it in LibreSSL, which is part of the reason why OpenSSL is such a mess.

Pressure from LibreSSL made Linux kernel developers implement a version of BSD's getentropy() and Linux is better for it.

[Hans 1]

Re: And LibreSSL isn't even an option on 32-bit Linux

Running 32-bit Linux today is already embarrassing, in 2020 even more so, in 2025, absolutely no excuse anymore ... in 2030 ? Hello, anybody in ???? in 2038 we will be mostly 128-bit ... wait and see ;-)

Go open source, hardware and software, that way you can control where your stuff runs and update as required.

[Skoorb]

Re: And LibreSSL isn't even an option on 32-bit Linux

Do remember that most ARM chips in use today are 32bl bit

And that root CAs tend to have stupidly long expiry dates on them.

This is an issue you can come up against today on new systems.

Linux implementing an additional 64 bit date type like BSD would be no bad thing, but that's unlikely to happen.

[Dan 55]

Re: And LibreSSL isn't even an option on 32-bit Linux

It's like the GNU stdlib not implementing strl functions because they come from BSD land. There are many people in Linux land who can argue till the cows come home for years about why they're not going to do something and their only real problem with it that it happened on BSD first.

[Anonymous Coward]

Re: And LibreSSL isn't even an option on 32-bit Linux

their only real problem with it that it happened on BSD first

Yup. The Not Invented Here syndrome never seems to expire..

[Hans 1]

Re: And LibreSSL isn't even an option on 32-bit Linux

Only, on GNU/Linux, most was first "invented" on BSD ... so, I do not really see that as a problem ... what I do see, though, is linux 32-bit support being retired today left, right and center ... this means "It's dead, Jim!" ... in 5 years time, for sure.

As for the other commentards, ARM 32-bit is probably going strong now, though, those 8 core 64-bit thingies are out already and have been for a while, mate ... things move on ... especially in freet@rd-land ... now, you are not going to make the same mistakes you made in the 80's, 90's, and 2000's ... open source is really the only option to keep your stuff up-to-date ... and NO, you cannot expect security updates for 12 years or more on a specific version, you have to move with the wave. In proprietary world, once they have you, they milk you for forever ... in the long run, freet@rd really makes a lot of sense ...

[-tim]

Re: And LibreSSL isn't even an option on 32-bit Linux

32 bit code isn't dead yet and some of us have been having that discussion in SPARC land for more than a decade.

99.999999999% of code that has any non zero value in the top 32 bits of a pointer is a bug (yeah, based on zero based page addresses and non randomized frame pointers etc).

99.9% of any code that isn't crypto that has non zero (except -1) on the top 32 bits of an int is buggy. Oddly enough that include most graphics code (the GPUs deal with smaller or much larger than 64 bits at a time)

Meanwhile 64 bit code tends to double the data moves and doubles the cpu power used moving around a great many zeros for the benefit that maybe it will work once the program has to cope with more than 4 billion bytes assuming it hasn't been swapping like mad for more than a month once it reaches that magic threshold. I've seen very few programs that can cope.

Of course there are programs that do make use of it but they are very rare or use memory in other ways.

[Robert Carnegie]

Although this isn't the place -

Are there certificates that are actually vouching now to be still secure in the year 2038?

By that time, I expect security to work by physically teleporting the user into the datacentre for biometric verification, then home again. Using IPv6. (This is what the quantum extensions to the specification are for. And patching your system is REALLY important then.)

Supporting date values after 2038 in current code is great. Using them at the moment seems absurd.

[Anonymous Coward]

Re: Although this isn't the place -

> Are there certificates that are actually vouching now to be still secure in the year 2038?

Root CAs are typically valid for 20+ years which is why this is becoming an issue now on embedded 32-bit systems, where LibreSSL is seriously becoming a non-option. The LibreSSL developers claim to have fixed all the 2038 issues, but this is only true if you're using BSD or a true 64-bit ABI. And to be honest, they've caused this problem intentionally by removing the 32-bit ABI support from v2.3.1.

<a href="https://lwn.net/Articles/563285/>This article</a> explains some of the challenges facing Linux and why changing the 32-bit ABI isn't an easy solution, and also why it was so much easier for OpenBSD to make the move to 64-bit time_t, even on 32-bit hardware.

I know the LibreSSL developers favor BSD but their attitude is pretty shitty as they know that the Linux 32-bit ABI can't easily accommodate 64-bit time_t in the same way that BSD has done. This is going to force 32-bit ABI users back to OpenSSL. Maybe we need one of Linus' rants where he tells the LibreSSL guys to go fck themselves.

[Korev]

Re: And LibreSSL isn't even an option on 32-bit Linux

Maybe on the desktop and server space, but what about on tiny embedded systems?

[All names Taken]

Oh no! No! No! No!

Oh no Microsoft! No!

Email arrived from Microsoft Windows Store:

Click here to download your tax invoice pdf

Invoice Tax Reference mghfggyugyvjluhghbhuujbh

How could they do that?

All it takes is one click on a dodgy link and ... well maybe that is the intention? Software sales down, compromise Windows Store user accounts and encourage users to buy new kit?

Edit: apologies for usurping the post but it seems relevant in terms of consequences regarding online security: best systems in the world can be cocked up by dodgy practice?