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.
GUIDs are meant to be unique, not random. Statisticaly speaking there is no such thing as random number when it’s on digital machine. Actual diameter of 100 M8 bolts will have random distribution, actual resistance of 100 0.5W 1kΩ resistors will have random distribution but digital data cannot have one.
Digital data does indeed not have any “randomness” if executed in a perfect machine.
But introduce anything that gets affected by the surrounding world, and suddenly randomness creeps in.
A couple of common sources of randomness in the computer world is:
User input in the forms of time between keystrokes, or pointer movement.
RAM fetch delays. (gets affected by both cache and other applications.)
Power cycling of SRAM arrays. (SRAM that isn’t biased to 1 or 0 will tend to fall randomly into one or the other due to manufacturing tolerances. But only a fraction of an array tends to be properly random.)
There is also the once in a blue moon computational error. But relying on this for randomness isn’t ideal, since most processors aims to not have computational errors.
But in the end.
We don’t need much randomness to be random.
Since hashing large amounts of slightly random data is a fairly effective way to make something exceptionally random. (unless the hashing algorithm is weighted, or simply missing certain output values, among other flaws.)
But yes, it isn’t always important for a unique ID to be random.
Some computers do have actual random number generators built in. Some use one or more ring oscillators (an odd number of NOT gates in a ring. If implemented in silicon it is not uncommon to have 501+ NOT gates in a ring to maximise jitter – a normally undesired feature of all oscillators). It just toggles on and off and drifts in relation to system clocks that use quartz crystals for stability. If the output from a ring oscillator is sampled on the rising edge of a stable clock using a D-type flip-flop random numbers can be extracted.
There are other ways, but for digital circuits ring oscillators are an easy source of random numbers. It does use a lots of power, so it could be powered off if enough entropy has been stored in a random pool.
I just found out that ring oscillators also get added to wafers (The hardware equivalent of software “Hello World!”) between chips on wafers as part of the scribe lines. With controlled temperatures and voltages, variations in the jitter of the ring oscillators can be used to measure and characterise how accurately and precisely a wafer was processed during production.
Free running ring oscillators is indeed a rather trivial source for randomness. It has some general patterns to it over time, but as long as it has some degree of non deterministic behavior, then it is fine after some hashing. (oversimplifying here though…)
In regards to power, it can actually be fairly efficient, depends on how often we want to be able to check in on it. If it is once every few seconds then it can run fairly slowly and still achieve a mostly unknown state by the time we sample it.
You can get truly random noise from the quantum effects of biased diodes, don’t need external sources of randomness
“most processors aims to not have computational errors” that is most certainly not true, you can see over and over again in every FPU that accuracy is just about always sacrificed in the name of faster execution speed. You really think they are doing full series expansion calculations in there? Nope, they are taking every shortcut Trig operations in particular (esp those close to the axes) can be really terrible and you might need to “roll your own” if you need accuracy.
You might have your opinion of how random and predictable a GUID needs to be, but the behavior of the software you are using is the final arbiter as to how safe and secure it needs to be. If they are using it as an API key then it needs to be very random and very secure.
There is indeed a lot of interesting randomness that can be obtained from noise.
Some TRNG solutions I have seen have just been a differential gain stage that has a terminated input, practically amplifying resistive noise, then low pass filtered a bit before amplified further and eventually squared up to drive some counter.
Another is to use a photo sensor (or a camera sensor) and look at cosmic rays. But this is slow and not that practical in all environments. But at least very far from deterministic.
And yes, it is all down to the end application how random a GUID/UUID needs to be in practice. If used as a general ID then it partly isn’t too important. If used as a key for any form of encryption then perhaps it should be unpredictable. (Though, proper security should likely rely on better security practices in general. Even if this is another huge can of worms in itself.)
“Another is to use a photo sensor (or a camera sensor) and look at cosmic rays. ”
Smoke detector.
I was wondering – say we have a stable 1 [MHz] crystal oscillator. If we poke the value we get 50% chance to get 1. Now if we poke it 8 times (manually to avoid regular time intervals) and consolidate results, would that generate a random number between 0-255? So in other words – if we poke a value every time a key is pressed on keyboard or mouse and accumulate results for last 8 events would that be a good source of random numbers? If yes would that be still valid for a 8 bit counter instead of oscillator? Sure 8 bit counter would need more time to restart but at 1 [GHz] that would be still quite a few keystrokes between pressing the buttons.
Using an oscillator to run an overflowing counter that we sample the state of each time the user presses a key is indeed a way to generate random numbers.
We generally want our counter to overflow a bit faster than our expected user is able to type. While a faster clock speed for the counting will allow us to have a longer counter and get more bits per sample.
And this is a rather effective way to generate random numbers. But with one very very big catch!
Keyboards have pulling rates, like any other input device.
And this effectively “bins” our samples in time. As an example, if the keyboard is pulled at 1 KHz, then we can only see 1 ms differences.
This either risks our RNG to produce the same value each keystroke if the overflow period is an integer multiple of the pulling rate.
Or produce a predictable sequence of values. Since the two frequencies will go in and out of phase over time, if the difference in frequency is small the period of this phase change will be very long and make predictable guesses of what rough value the RNG spit out a possibility.
But counting ms between keystrokes works fairly well too. Sampling many keystrokes over time will tend to provide a suitable amount of randomness and throwing on a bit of hashing on top to mix it all up is a simple solution to get more useful randomness from it.
Another common source of RNG is the LSB of an audio input, it often is buried in the noise and is something one can sample at well into the ten’s of KHz, effectively giving a new mostly random bit each time it is sampled. (Practically doesn’t matter if the microphone line is used for something else, the LSB is still mostly noise.)
Thanks that explains a bit.
About audio – I was always sure that any normal audio recording (like song, movie score, speech etc. but not periodic waveform) can be treated as random signal. It is hard to predict next number even if you know previous minutes of signal. Specially with classical music or movie scores where tempo, tune, volume and other factors change quite often. Maybe distribution is not perfect but it should be very hard to predict next sample knowing previous 3 minutes of 44.1kHz 16bit recording (with exceptions like 4′33″ by John Cage)
And why can’t it have a random distribution? Doesn’t that depend on the seed or source of the random funxtion?
And that’s supposed to be function not funxtion…
Would like to read more on the CVE’s: CVE-2022-41674, CVE-2022-42719, and CVE-2022-42720, but I haven’t bee able to dig up any POC code on them, or even what the actual issue is aside from a vague one-liner description.
Yeah, these seem like they could be a big problem if they are easy to exploit.
Some sources say that they affect only 5.x series of kernels, but not sure about that.
https://github.com/PurpleVsGreen/beacown
Has poc and few more details
I often want actual random numbers for things, and swapped to using a esp32 some years ago to generate them.
It has a true random one based on “These true random numbers are generated based on the thermal noise in the system and the asynchronous clock mismatch. ” The thermal noise comes from the high speed ADC (page 590 in the doc).
I’ve read quite a lot of analysis on the output, and it seems pretty good – certainly better than what I can generate on the pc easily..
And yes, I also use it to make the ‘guids’ that I use on some things. I can put one here if anyone thinks they can get any information out of it…
your PC’s CPU has way better hardware random number generators built-in already T__T