This Week In Security: CVSS 4, OAuth, And ActiveMQ

We’ve talked a few times here about the issues with the CVSS system. We’ve seen CVE farming, where a moderate issue, or even a non-issue, gets assigned a ridiculously high CVSS score. There are times a minor problem in a library is a major problem in certain use cases, and not an issue at all in others. And with some of those issues in mind, let’s take a look at the fourth version of the Common Vulnerability Scoring System.

One of the first tweaks to cover is the de-emphasis of the base score. Version 3.1 did have optional metrics that were intended to temper the base score, but this revision has beefed that idea up with Threat Metrics, Environmental Metrics, and Supplemental Metrics. These are an attempt to measure how likely it is that an exploit will actually be used. The various combinations have been given names. Where CVSS-B is just the base metric, CVSS-BT is the base and threat scores together. CVSS-BE is the mix of base and environmental metrics, and CVSS-BTE is the combination of all three.

Another new feature is multiple scores for a given vulnerability. A problem in a library is first considered in a worst-case scenario, and the initial base score is published with those caveats made clear. And then for each downstream program that uses that library, a new base score should be calculated to reflect the reality of that case. Continue reading “This Week In Security: CVSS 4, OAuth, And ActiveMQ”

Proposed European Electronic ID Law Raises Concerns

The harmonisation of standards for electronic identification across the EU should normally be soporific enough to send even the most Club-Mate-hyped hacker straight to sleep, but as Computer Weekly reports, discussion of this reform in the EU corridors of power has caused significant unrest among cyber security experts. Just how can providing Europeans with a harmonised digital ID be so controversial? As you might imagine, the devil lies in the detail.

At issue is the eIDAS Regulation, a system which, in the words of its website: “ensures that people and businesses can use their own national electronic identification schemes (eIDs) to access public services available online in other EU countries,” and “creates a European internal market for trust services by ensuring that they will work across borders and have the same legal status as their traditional paper-based equivalents,” and the point of concern lies with its application to websites. The EU want to ensure that Europeans can digitally verify businesses as well as individuals they deal with, and since that includes websites, they want to insert a provision allowing countries to mandate their own trusted root certificates. At a stroke, this opens the potential for state actors to snoop on all encrypted online traffic, something which would compromise the security of all.

Sadly for Europeans, this isn’t the only questionable online regulation effort from that region.

Thanks [Joyce Ng] for the tip.

This Week In Security: 1Password, Polyglots, And Roundcube

This week we got news of a security incident at 1Password, and we’re certain we aren’t the only ones hoping it’s not a repeat of what happened at LastPass. 1Password has released a PDF report on the incident, and while there are a few potentially worrying details, put into context it doesn’t look too bad.

The first sign that something might be amiss was an email from Okta on September 29th — a report of the current list of account administrators. Okta provides authentication and Single Sign-On (SSO) capabilities, and 1Password uses those services to manage user accounts and authentication. The fact that this report was generated without anyone from 1Password requesting it was a sign of potential problems.

And here’s the point where a 1Password employee was paying attention and saved the day, by alerting the security team to the unrequested report. That employee had been working with Okta support, and sent a browser session snapshot for Okta to troubleshoot. That data includes session cookies, and it was determined that someone unauthorized managed to access the snapshot and hijack the session, Firesheep style.

Okta logs seemed to indicate that the snapshot hadn’t been accessed, and there weren’t any records of other Okta customers being breached in this way. This pointed at the employee laptop. The report states that it has been taken offline, which is good. Any time you suspect malicious action on a company machine, the right answer is power it off right away, and start the investigation.

And here’s the one part of the story that gives some pause. Someone from 1Password responded to the possible incident by scanning the laptop with the free edition of Malwarebytes. Now don’t get us wrong, Malwarebytes is a great product for finding and cleaning the sort of garden-variety malware we tend to find on family members’ computers. The on-demand scanning of Malwarebytes free just isn’t designed for detecting bespoke malicious tools like a password management company should expect to be faced with.

But that turns out to be a bit of a moot point, as the real root cause was a compromised account in the Okta customer support system, as revealed on the 20th. The Okta report talks about stolen credentials, which raises a real question about why Okta support accounts aren’t all using two-factor authentication.

Continue reading “This Week In Security: 1Password, Polyglots, And Roundcube”

This Week In Security: Browser Exploits, Play Protect, And Turn ON Your Firewall!

Google Chrome has done a lot of work on JavaScript performance, pushing the V8 engine to more and more impressive feats. Recently, that optimization has one more piece, the Maglev compiler, which sits between Sparkplug and TurboFan, as a mid-tier optimization step. With a Just In Time (JIT) system, the time saving of code optimization steps has to be carefully weighed against the time costs, and Maglev is another tool in that endless hunt for speed. And with anything this complicated, there’s the occasional flaw found in the system. And of course, because we’re talking about it here, it’s a security vulnerability that results in Remote Code Execution (RCE).

The trick is to use Maglev’s optimization against it. Set up a pair of classes, such that B extends A. Calling new B() results in an attempt to use the constructor from A. Which works, because the compiler checks to make sure that the constructors match before doing so. There’s another way to call a constructor in JS, something like Reflect.construct(B, [], Array);. This calls the B constructor, but indicates that the constructor should return an Array object. You may notice, there’s no array in the A class below. Tricking the compiler into using the parent class constructor in this fashion results in the array being uninitialized, and whatever happens to be in memory will set the length of the array. Continue reading “This Week In Security: Browser Exploits, Play Protect, And Turn ON Your Firewall!”

This Week In Security: Curl Reveal, Rapid Reset DDoS, And Libcue

Curl gave us all a big warning that a severe security problem had been found in that code-base. Given the staggering number of Curl installs around the world, we held our collective breath and waited for the bombshell to drop this Wednesday. It turns out, it’s not quite as bad as feared — so long as you don’t have a SOCKS proxy.

In hindsight, shipping a heap overflow in code installed in over twenty billion instances is not an experience I would recommend. — Daniel Stenberg

The trouble started when the SOCKS5 proxy support was converted to a non-blocking implementation. It’s a win for libcurl to work on requests asynchronously, but refactoring code and new features always runs a bit of risk. SOCKS5 proxying has some quirks, like allowing DNS resolution to happen locally or at the proxy. The new async code starts out with:

bool socks5_resolve_local =
(proxytype == CURLPROXY_SOCKS5) ? TRUE : FALSE;

First off, unnecessary ternary is unnecessary. But note that this local variable gets set by the proxytype. If that’s CURLPROXY_SOCKS5_HOSTNAME, then it uses remote resolution. But inherited from old code is a check for a hostname that is too long for a SOCKS request (255 bytes). This code converts back to local resolution in this case.

The important detail here is that this function is now a state machine, that potentially runs multiple times for a single request, to achieve that asynchronous execution. The check for a too-long hostname only happens during the initialization state. Copying the hostname into the buffer happens in a different state. If setting up the connection takes enough time, the function will return and be executed again when something has changed. The ternary check runs again, but not the hostname-too-long. So if set to do remote resolution with a long enough host name, execution slips through this edge case, and the long hostname is copied into a too-small buffer.

It’s safe to assume that this heap overflow can result in arbitrary code execution. The fix has landed in 8.4.0, after being present for 1,315 days. [Daniel] goes ahead and gets ahead of the inevitable suggestion that Curl should be written in rust or another memory-safe language. Curl was started before those alternatives existed, and there is a very slow effort to move portions of the project to memory-safe languages. And you’re welcome to help out. Continue reading “This Week In Security: Curl Reveal, Rapid Reset DDoS, And Libcue”

This Week In Security: Looney Tunables, Not A 0-day*, And Curl Warning

This week starts out with a nifty vulnerability in the glibc dynamic loader. This is an important step in running a binary executable on Linux, as it pulls the list of required shared libraries, and loads those libraries into memory. Glibc also includes a feature to adjust some runtime settings, via the GLIBC_TUNABLES environment variable. That’s where the vulnerability resides, and researchers from Qualsys obviously had a bit of fun in taking inspiration to pick the vulnerability name, “Looney Tunables”.

The problem is memory handling in the sanitizing parser. This function iterates through the environment variable, looking for strings of tunable1=aa, separated by colons. These strings get copied to the sanitized buffer, but the parsing logic goes awry when handling the malformed tunable1=tunable2=AAA. The first equals sign is taken at face value, copying the rest of the string into the buffer. But then the second equals sign is also processed as another key=value pair, leading to a buffer overflow.

The reason this particular overflow is interesting is that if the binary to be run is a Set-User-ID (SUID) root application, the dynamic loader runs as root, too. If the overflow can achieve code execution, then it’s a straightforward privilege escalation. And since we’re talking about it, you know there’s a way to execute code. It turns out, it’s possible to overwrite the pointer to the library search path, which determines where the dynamic loader will look for libraries. Tell it to look first in an attacker-controlled location, and you can easily load a malicious libc.so for instant code execution.

This vulnerability affects many Linux distros, and there’s already a Proof of Concept (PoC) published. So, it’s time to go check for updates for cve-2023-4911. Continue reading “This Week In Security: Looney Tunables, Not A 0-day*, And Curl Warning”

This Week In Security: Magic Packets, GPU.zip, And Enter The Sandman

Leading out the news this week is a report of “BlackTech”, an Advanced Persistent Threat (APT) group that appears to be based out of China, that has been installing malicious firmware on routers around the world. This firmware has been found primarily on Cisco devices, and Cisco has released a statement clarifying their complete innocence and lack of liability in the matter.

It seems that this attack only works on older Cisco routers, and the pattern is to log in with stolen or guessed credentials, revert the firmware to a yet older version, and then replace it with a malicious boot image. But the real fun here is the “magic packets”, a TCP or UDP packet filled with random data that triggers an action, like enabling that SSH backdoor service. That idea sounds remarkable similar to Fwknop, a project I worked on many years ago. It would be sort of surreal to find some of my code show up in an APT.

Don’t Look Now, But Is Your GPU Leaking Pixels

There’s a bit debate on who’s fault this one is, as well as how practical of an attack it is, but the idea is certainly interesting. Compression has some interesting system side effects, and it’s possible for a program with access to some system analytics to work out the state of that compression. The first quirk being leveraged here is that GPU accelerated applications like a web browser use compression to stream the screen view from the CPU to the GPU. But normally, that’s way too many pixels and colors to try to sort out just by watching the CPU and ram power usage.

And that brings us to the second quirk, that in Chrome, one web page can load a second in an iframe, and then render CSS filters on top of the iframe. This filter ability is then used to convert the page to black and white tiles, and then transform the white tiles into a hard-to-compress pattern, while leaving the black ones alone. With that in place, it’s possible for the outer web page to slowly recreate the graphical view of the iframe, leaking information that is displayed on the page.

And this explains why this isn’t the most practical of attacks, as it not only requires opening a malicious page to host the attack, it also makes some very obvious graphical changes to the screen. Not to mention taking at least 30 minutes of data leaking to recreate a username displayed on the Wikipedia page. What it lacks in practicality, this approach makes up for in cleverness and creativity, though. The attack goes by the GPU.zip moniker, and the full PDF is available. Continue reading “This Week In Security: Magic Packets, GPU.zip, And Enter The Sandman”