Ubuntu Takes A U-Turn with 32-Bit Support

Canonical, maker of the popular Ubuntu Linux distribution, has revived support for 32-bit libraries after feedback from WINE, Ubuntu Studio, and Steam communities.

Last week Canonical announced that its engineering teams decided that Ubuntu should not continue to carry i386 forward as an architecture (https://ubuntu.com/blog/statement-on-32-bit-i386-packages-for-ubuntu-19-10-and-20-04-lts). "Consequently, i386 will not be included as an architecture for the 19.10 release, and we will shortly begin the process of disabling it for the eoan series across Ubuntu infrastructure," wrote Will Cooke, Director of Ubuntu Desktop at Canonical.

However, the news was not received well. Canonical was criticized for the move. Responding to the uproar, Canonical decided to continue to support 32-bit applications.

As Steve Langasek, a Debian and Ubuntu developer wrote in a mailing list, maintaining support for 32-bit libraries is "a cost largely paid by Canonical (both in terms of infrastructure and in terms of engineering work to keep the base system working). It's not very compelling to say that Canonical should continue bearing these costs out of pocket on the grounds that some other companies are unwilling to update their software to an ISA from this millennium :)"

OpenSSH Fixes Side Channel Attacks

There is a rise in memory side-channel vulnerabilities like RAMBleed, Spectre, and Meltdown. OpenSSH is often at the center of attacks where a bad actor "exploits memory read vulnerabilities to steal secret SSH private keys from the restricted memory regions of the system," according to The Hacker News.

The root cause of this issue is the fact that the OpenSSH agent stores a copy of the SSH keys in the memory (RAM of CPU), eliminating the need of entering a passphrase to log into the server via SSH. Since these keys are stored in either RAM or CPU in plaintext, they are susceptible to attacks.

The OpenSSH community is now fixing this issue through an update. OpenSSH will now encrypt private keys before storing them into the system memory.

"Attackers must recover the entire prekey with high accuracy before they can attempt to decrypt the shielded private key, but the current generation of attacks have bit error rates that, when applied cumulatively to the entire prekey, make this unlikely," said Damien Miller of the OpenBSD project on a mailing list (https://marc.info/?l=thn&m=156109087822676).

Firefox Fixes Error that Crashed HTTPS Pages

Mozilla has made changes to its Firefox browser that helps sysadmins fix TLS errors due to HTTPS (https://blog.mozilla.org/security/2019/07/01/fixing-antivirus-errors/). These errors are triggered by antivirus software that try to intercept secure connections over HTTPS.

The cause of the problem was the fact that Firefox trusts only those Certificate Authorities (CAs) that are listed in its own store, whereas antivirus software systems use their own CAs. "The antivirus products relying on other trusted CAs provided by the operating system (OS) are not allowed to intercept HTTPS connections on Firefox," said The Hacker News.

This conflict between Firefox and antivirus software led to users experiencing crashed HTTPS pages showing errors like "SEC_ERROR_UNKNOWN_ISSUER."

To fix the issue, Mozilla has created a mechanism to detect when a Firefox error is caused by a MITM. Users can enable the 'enterprise roots' preference that allows Firefox to import any root CAs that have been added to the OS by the user, an administrator, or a program that has been installed on the computer.

This option is available only on Windows and MacOS.

"It might cause some concern for Firefox to automatically trust CAs that haven't been audited and gone through the rigorous Mozilla process. However, any user or program that has the ability to add a CA to the OS almost certainly also has the ability to add that same CA directly to the Firefox root store," said Mozilla in a blog post.