Up first this week is a quintet of vulnerabilities in the Linux kernel’s wireless code. It started with [Soenke Huster] from TU Darmstadt, who found a buffer overwrite in mac80211 code. The private disclosure to SUSE kernel engineers led to a security once-over of this wireless framework in the kernel, and some other nasty bugs were found. A couple result in Denial-of-Service (DOS), but CVE-2022-41674, CVE-2022-42719, and CVE-2022-42720 are Remote Code Execution vulnerabilities. The unfortunate bit is that these vulnerabilities are triggered on processing beacon frames — the wireless packets that announce the presence of a wireless network. A machine doesn’t have to be connected or trying to connect to a network, but simply scanning for networks can lead to compromise.
The flaws were announced on the 13th, and were officially fixed in the mainline kernel on the 15th. Many distros shipped updates on the 14th, so the turnaround was quite quick on this one. The flaws were all memory-management problems, which has prompted a few calls for the newly-merged Rust framework to get some real-world use sooner rather than later.
Fortinet
Much of Fortinet’s lineup, most notable their Fortigate firewalls, has a pre-auth authentication bypass on the administrative HTTP/S interface. Or plainly, if you can get to the login page, you can break in without a password. That’s bad, but at this point, you *really* shouldn’t have any administrative interfaces world-accessible on any hardware. Updated firmware is available.
More than just a couple days have passed, so we have some idea of the root problem and how it was fixed. It’s a simple one — the Forwarded HTTP headers on an incoming request are unintentionally trusted. So just send a request with Forwarded:for and Forwarded:by set to 127.0.0.1, and it falls through into code logic intended for internal API calls. Add a trusted SSH key, and pop, you’re in. Whoops.
GitHub Tokens Learn New Tricks
GitHub has been waging a bit of a mini-war on password use for SSH connection to their service. This has some obvious benefits, but one of the downsides is that a token gets permanently installed on the machine you’re developing from, and it has access to your whole GitHub account. That’s a real problem if you do any dev work on shared servers. Thankfully, the folks at GitHub have recognized the error of their ways, and rolled out more selective access controls for those tokens. It might be time to go audit your GitHub tokens, revoke the “classic” tokens, and regenerate with strict controls.
Text4Shell
If there’s anything worse than the attempt to make political scandals seem worse by slapping “gate” to the end of them, it’s the new trend of adding “4shell” to Java vulnerabilities. And in that vein, we have text4shell. It’s the quirk that StringSubstitutor.replace() and StringSubstitutor.replaceIn() can do string lookups on included strings — and that lookup can run arbitrary Java code:
final StringSubstitutor interpolator = StringSubstitutor.createInterpolator();
String out = interpolator.replace("${script:javascript:java.lang.Runtime.getRuntime().exec('touch /tmp/foo')}");
System.out.println(out);
It looked for a while like modern JDK versions were unaffected, but it turns out that a slightly different approach gets us the exact same code execution issue.
Hi Erik, I received some question related to the JDK versions affected by this vulnerability. Can you please update your blog post to make it clear that all JDK versions are vulnerable? Nashorn is effectively not available in modern JDKs but JEXL is pic.twitter.com/rY2J9VEZrX
— Alvaro Muñoz
(@pwntester) October 18, 2022
There are already tools developed to catch this particular flaw, though the normal Java issue of libraries compiled-in to the final jarfile will be a problem here, too. Thankfully this one doesn’t look to have quite the same exposure as log4shell.
Non-random GUIDs
UUIDs or GUIDs, whichever you prefer to call them, are a Universally Unique IDentifier, and they get used all over the place. What you might not know is that there is an actual RFC, and it specifies versions with different generation algorithms. When you see an UUID, the first number of the third set specifies which version it is. So, 589bc816-502f-11ed-b8f4-18c04d808bd7 is a version 1 UUID. That’s interesting, because it’s not randomly generated, it’s based on the generating computer’s MAC address and timestamp. Version 4 is the only randomly generated UUID scheme, so all the others are deterministic. And if a password reset link uses a UUID for its secret key? You might just have a way into the account.
[Daniel Thatcher], the researcher behind this story has released guidtool, a Python script to extract all the details from a V1 UUID string. That’s a lot of information given away by a string you might assume to be random.
Microsoft Insecure Driver List
Signed Windows drivers with known security flaws are either a boon, or a huge problem, depending on whether you’re red- or blue-teaming. The idea is that an unprivileged user can load a signed driver, exploit the known flaw, and get escalation of privilege. Microsoft knows all about this issue, and maintains a list of known-vulnerable drivers, blocking them from loading. If, that is, you have *very* loose definitions of “maintain” and “list”. Apparently it hasn’t been updated in three years, and the Windows Server 2019 version contains a whopping two drivers. It looks like after repeated demonstration of problems, Microsoft is once again properly maintaining this list, though there still seems to be user intervention required to install and update it.
This Week in Security: Linux WiFi, Fortinet, Text4Shell, and Predictable GUIDs
Source: Manila Flash Report
0 Comments