DNSSEC is the system that allows for cryptographically secure DNS. It’s all based on a root cryptographic key, maintained by the Internet Assigned Numbers Authority (IANA). Ever wondered where the root Key Signing Key is stored, and how it’s accessed? Four times a year, a ceremony is held where the root key is pulled out of a physical safe, and maintenance tasks are performed in front of a group of witnesses.

Such an event was scheduled for February 12th, but a teensy problem was discovered. One of the safes that holds the key media had a broken lock, and the root key signing key was inaccessible for a few days while repairs were effected. The open nature of IANA means that much of their operations are publicly reported, and you can even watch the key signing ceremony, which was finally held on February 16th.

OpenSSH adds FIDO support

Version 8.2 of OpenSSH was just released, and while it contains the normal collection of bugfixes and improvements, the standout feature is support for FIDO/U2F two factor authentication devices.

U2F, Universal 2nd Factor, is the open standard for authentication devices, like the Yubikey or Google’s Titan key. Having support for it in SSH is a huge security win. There is one gotcha here to be aware of: The U2F protocol uses a challenge-response scheme, where the challenge is first sent to the hardware token, which then generates the response. This scheme is great for security, but doesn’t automatically function in one of the typical use cases of SSH. You can use U2F to connect from a local machine to a remote host, physically plugging you token into a local USB port. The problem arises if you need to SSH from that remote host to yet another machine — the remote authentication process no longer has a path to interact with the local USB device. It may sound convoluted, but this scenario is common for many of us.

It seems that OpenSSH won’t automatically proxy the U2F authentication in these cases, but there is a utility, PAM_SSH_AGENT_AUTH that can likely do the proxying automatically.

SonicWall

If we’ve learned anything from watching the security news for the last few months, it’s that even large corporations that make security-related products are not immune to security problems. The latest reminder of this truism? Sonicwall. [Alain Mowat] took a look at a trial version of their Secure Remote Access product, which he downloaded as a VM image. He found a run-of-the-mill SQL injection attack, and an interesting buffer overflow. That overflow is in the code that parses the user-agent string of an incoming HTTP connection. In the event of a Safari browser, an eleven character buffer is created, and the user-agent text up to the next space character is copied in. No further checks are done, leading to trivial buffer overflow and compromise.

[Alain] reported his findings, and Sonicwall has released an advisory and fix. Months after that fix was released, he did a partial web scan, testing for a third, minor issue he found, a directory transversal bug. Upon finding multiple devices that still show signs of still being vulnerable, he opted not to publish any exploit code.

V4L2

The Linux kernel’s video capture drivers, V4L2, had a bug related to mutex locking during the tear-down of a video stream. A mutex, or MUTual EXclusion object, is little more than a flag used to manage which thread is currently using a memory location. Two threads writing to the same buffer at once would inevitably corrupt that data, so a mutex is used to “lock” that data while each thread is manipulating it.

The bug was the fact that the mutex lock was released too early, and a bit naively. An attacker could win the race condition, and push a buffer pointer onto the V4L2 queue. That pointer points to now-freed memory, meaning that it is possible to allocate a malicious object there, and execute code when streaming is started again. [Alexander Popov] walks us through the entire exploit process, and it’s worth the read.

Since the vulnerability is specifically in the vivid driver, and the Linux Kernel doesn’t allow a non-root user to load kernel modules, the attack surface here is very slim. It was fixed in late 2019, but is still a great example of a kernel exploit to learn from.

This One Weird Windows Trick

Windows User Group Policy is one of the ways that a user account can be limited in access to a computer, for example disabling access to the task manager. [David Wells] brings us a nifty little bypass he found. (He’s also responsible for the clickbait title.)

It boils down to the default Windows behavior of checking for “ntuser.man” in a user’s profile folder. The file location is intended to be used for a mandatory profile, settings applied to all users. If that file hasn’t been created by an administrator, however, the profile folder is writable by the user. So, need to make changes to allow a few extra privileges? Write them out to the missing file, log out, and back in. Windows will find the file, and process it as if it’s gospel.

Crypto AG

The massive story that came across the desk this week is about Crypto AG, a cryptography company based in Switzerland. It was founded by [Boris Hagelin], a cryptographer who first made his mark by building an alternative to the Enigma machine, the M-209, for the US forces during WWII. After the war, he moved back to Sweden to start his company. In 1951, a handshake deal with [William Friedman] of the AFSA (later reorganized into the NSA) meant that Crypto AG only sold their most advanced products to approved countries.

In 1970, the CIA and the West German BND worked together to secretly purchase Crypto AG from [Hagelin]. Together with assistance from the NSA, they provided vulnerable encryption machines to many governments around the globe, and then used their knowledge to decrypt traffic generated with those machines. The incredible scheme lasted til at least the late 1990’s, possibly as late as 2018, and sounds like something straight out of a cold war novel.