OpenWrt announced a problem in opkg, their super-lightweight package manager. OpenWrt’s target hardware, routers, make for an interesting security challenge. A Linux install that fits in just 4 MB of flash memory is a minor miracle in itself, and many compromises had to be made. In this case, we’re interested in the lack of SSL: a 4 MB install just can’t include SSL support. As a result, the package manager can’t rely on HTTPS for secure downloads. Instead, opkg first downloads a pair of files: A list of packages, which contains a SHA256 of each package, and then a second file containing an Ed25519 signature. When an individual package is installed, the SHA256 hash of the downloaded package can be compared with the hash provided in the list of packages.
It’s a valid approach, but there was a bug, discovered by [Guido Vranken], in how opkg reads the hash values from the package list. The leading space triggers some questionable pointer arithmetic, and as a result, opkg believes the SHA256 hash is simply blank. Rather than fail the install, the hash verification is simply skipped. The result? Opkg is vulnerable to a rather simple man in the middle attack.
OpenWrt doesn’t do any automatic installs or automatic updates, so this vulnerability will likely not be widely abused, but it could be used for a targeted attack. An attacker would need to be in a position to MitM the router’s internet connection while software was being installed. Regardless, make sure you’re running the latest OpenWrt release to mitigate this issue. Via Ars Technica.
Wireguard V1.0
With the Linux Kernel version 5.6 being finally released, Wireguard has finally been christened as a stable release. An interesting aside, Google has enabled Wireguard in their Generic Kernel Image (GKI), which may signal more official support for Wireguard VPNs in Android. I’ve also heard reports that one of the larger Android ROM development communities is looking into better system-level Wireguard support as well.
Javascript in Disguise
Javascript makes the web work — and has been a constant thorn in the side of good security. For just an example, remember Samy, the worm that took over Myspace in ’05. That cross-site scripting (XSS) attack used a series of techniques to embed Javascript code in a user’s profile. Whenever that profile page was viewed, the embedded JS code would run, and then replicate itself on the page of whoever had the misfortune of falling into the trap.
Today we have much better protections against XSS attacks, and something like that could never happen again, right? Here’s the thing, for every mitigation like Content-Security-Policy, there is a guy like [theMiddle] who’s coming up with new ways to break it. In this case, he realized that a less-than-perfect CSP could be defeated by encoding Javascript inside a .png, and decoding it to deliver the payload.
Systemd
Ah, systemd. Nothing seems to bring passionate opinions out of the woodwork like a story about it. In this case, it’s a vulnerability found by [Tavis Ormandy] from Google Project Zero. The bug is a race condition, where a cached data structure can be called after it’s already been freed. It’s interesting, because this vulnerability is accessible using DBus, and could potentially be used to get root level access. It was fixed with systemd v220.
Mac Firmware
For those of you running MacOS on Apple hardware, you might want to check your firmware version. Not because there’s a particularly nasty vulnerability in there, but because firmware updates fail silently during OS updates. What’s worse, Apple isn’t publishing release notes, or even acknowledging the most recent firmware version. A crowd-sourced list of the latest firmware versions is available, and you can try to convince your machine to try again, and hope the firmware update works this time.
Anti-Rubber-Ducky
Google recently announced a new security tool, USB Keystroke Injection Protection. I assume the nickname, UKIP, isn’t an intentional reference to British politics. Regardless, this project is intended to help protect against the infamous USB Rubber Ducky attack, by trying to differentiate a real user’s typing cadence, as opposed to a malicious device that types implausibly quickly.
While the project is interesting, there are already examples of how to defeat it that amount to simply running the scripts with slight pauses between keystrokes. Time will tell if UKIP turns into a useful mitigation tool. (Get it?)
SMBGhost
Remember SMBGhost, the new wormable SMB flaw? Well, there is already a detailed explanation and PoC. This particular PoC is a local-only privilege escalation, but a remote code execution attack is like inevitable, so go make sure you’re patched!
I guess one could cynically regard the UKIP as a Google power grab to disable password hoarding utilities/hardware and make google accounts the one login to rule them all.
The simple solution to bypass UKIP would just slow down the typing and add random intervals like they said.
But UKIP could just slow rubber ducking down enough that its impractical for that attack.
Rather than having a superhuman typing speed it could be slowed to human speed.
Or you could just ban new devices connecting to the box.
Using validated HID devices is something very few OSes seems to even have a feature for.
Most OSes will blindly trust any HID that is plugged into the computer, and ask no questions about it ever.
That this is a wide open door for security exploits is rather obvious.
Though, a rubber ducky can be part of a keyboard, and only activate after a certain amount of time or inactivity. Rendering a “validation” system also prone to security errors. So we can’t even trust something that has worked flawlessly for months. If one wants to be that paranoid that is.
Making a rubber ducky useless in practice is honestly fairly simple.
Something a rubber ducky would have fairly poor odds of passing is a short random password.
Ie, to change system settings one would need to pass a simple test to see if it is actually a user making the setting.
The key would be proudly displayed on the screen. (also use text to speech for those that needs that.)
Even a relatively short key, like 5 digits, would make the rubber ducky able to pass only once every 100 000 attempts.
A 5 character alphanumeric key on the other hand, well that is suddenly a lot harder. (about 1 in 60 million. If we take “A” and “a” as the same character. But if we care about caps, then it will be 1 in 900 million. We could also toss in other characters like: ? = ) ( / & % ¤ # ” ! etc Making it even less likely that the comparatively blind rubber ducky passes our simple test.)
(And of cores, a few incorrect attempts would render the OS very skeptical of its trustworthiness. Ie, informing the user of the device’s odd behavior.)
Looking at typing speed/cadence isn’t always logical to be fair.
In some applications, the typing cadence can be frankly odd to be fair. Mainly because one isn’t typing text, but rather using short keys, or playing a game… So obviously we should only really care about a rubber ducky in scenarios where there is actually a risk.
There is a registry hack to force windows to ask for the admin password when running anything requiring admin access rather than the clickable ‘yes’. Defeats most escalation attacks.
I can’t run any interesting ducky scripts… for testing purposes….
UKIP? Without even looking at TFA’s date I’d bet it’s April 1st. Not only based on the acronym. The whole idea is fairly stupid.
It’s dated march 10th. Even that aside, don’t forget that april 1st was the gmail launch date.
Came for the ZOOM tidbit…
Er, and Zoom?
It’s mentioned in the title but I couldn’t see it in the article (at the time of reading – damn you if you add it in after the fact! -_- )
In case anyone did want to read something about zoom, they could always hit-up Ars Technica how have all the dirt (past and present) about them and even a more recent article about some suggestions on what to do if you must use it..
https://arstechnica.com/information-technology/2020/04/security-tips-every-work-from-homer-needs-to-know-about-zoom-right-now/
>A Linux install that fits in just 4 MB of flash memory is a minor miracle in itself
The comment is out of date as OpenWRT no longer support that.
FYI: https://openwrt.org/supported_devices
>DO NOT BUY DEVICES WITH 4MB FLASH / 32MB RAM if you intend to flash an up-to-date and secure OpenWrt version (18.06 or later) onto it! See 4/32 warning for details.
>1) 4/32 devices do not have sufficient resources (flash and/or RAM) to provide secure and reliable operation. See OpenWrt on 4/32 devices what you can do now.
>2) OpenWrt support for 4/32 devices will end after 2019. After 19.07, no further OpenWrt images will be built for 4/32 devices. See OpenWrt on 4/32 devices what you can do now.
The latest release, 19.07.2, still has firmware built for 4 Meg devices, so it’s not entirely out of date. https://downloads.openwrt.org/releases/19.07.2/targets/ath79/tiny/
Even in trunk, it appears that it’s still possible to build firmware for 4 Meg. Just don’t expect to install anything other than LuCI.
> a 4 MB install just can’t include SSL support..
BS
4MB sounds like a tremendous amount of code to be fair.
Though, I guess a large portion wouldn’t be code, but rather large libraries of human readable text for a console.
Not to mention various other stuff like locally stored encryption keys for ensuring that SSL certificates and such actually work… So 4MB can quickly become rather tiny.
But I would also be of the opinion that there likely is sufficient space in 4MB for SSL support, though one might need to toss out something else in the process.
There may already be crypto support in hardware, to leverage.
Text compresses 4:1 if you have to.
4MB is a lot, until you realize that in 4 MB you have to fit a Kernel, an init image, and a full filesystem. How big is the kernel on the machine you’re using now? On my machine, that’s 11 MB by itself.
A 4 Meg OpenWrt install will not give you SSL support. libopenssl itself is 1.4 Megs when compressed, according to https://downloads.openwrt.org/releases/packages-19.07/x86_64/base/
Oh, lovely, a systemd *and* D-Bus vulnerability! I can hear all the old-school Linux devs whistling an “I told you so” tune from here.
Just saw Zoom CEO sold all his shares because it came out its not really end-to-end. I use to use Keybase for chat, don’t know about video conferencing though. I’m good with a strong VPN that keeps no logs and using a custom DNS(9.9.9.9) rather than ISP.
Some years ago, the hackaday.io site would let you inject JavaScript in your profile, letting you run arbitrary code on other people’s accounts, oops! I stkk have the stickers HAD t-shirt I got for reporting it <3