Working hard to beat Adobe?
I'm sure another Flash patch with 50 fixes will come out to put it back on top!
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 …
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...
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.
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.
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.
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.
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.
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.
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.
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 ...
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.
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.
> 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.
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?
The latest version of OpenSSL v3, a widely used open-source library for secure networking using the Transport Layer Security (TLS) protocol, contains a memory corruption vulnerability that imperils x64 systems with Intel's Advanced Vector Extensions 512 (AVX512).
OpenSSL 3.0.4 was released on June 21 to address a command-injection vulnerability (CVE-2022-2068) that was not fully addressed with a previous patch (CVE-2022-1292).
But this release itself needs further fixing. OpenSSL 3.0.4 "is susceptible to remote memory corruption which can be triggered trivially by an attacker," according to security researcher Guido Vranken. We're imagining two devices establishing a secure connection between themselves using OpenSSL and this flaw being exploited to run arbitrary malicious code on one of them.
A bug in OpenSSL certificate parsing leaves systems open to denial-of-service attacks from anyone wielding an explicit curve.
The vulnerability stems from a bug in the BN_mod_sqrt() function, which the OpenSSL team said is used to parse certificates that "contain elliptic curve public keys in compressed form or explicit elliptic curve parameters with a base point encoded in compressed form." As it turns out, all you need to do to trigger an infinite loop in BN_mod_sqrt() is hand an OpenSSL-based application or service a certificate with invalid explicit curve parameters.
This parsing happens prior to verification of the certificate's signature. Slip a bad certificate to any app or server using BN_mod_sqrt() to parse certs, and the software will get caught in the loop and stop working.
The OpenSSL team has released version 3.0 of its eponymous secure communications library after a lengthy gestation period.
Coming nearly three years after its predecessor, version 1.1.1, the update lays claim to 17 alpha releases, two beta releases, and more than 7,500 commits. Equally significant is a near-doubling of the amount of documentation since upgrading an application to use it might not be an entirely simple process.
"OpenSSL 3.0 is a major release and not fully backwards compatible with the previous release," explained Matt Caswell of the OpenSSL Management Committee.
Biting the hand that feeds IT © 1998–2022