Author: Jonathan Bennett

523 Articles

Saving Apollo By Decoding Core Rope

November 4, 2023 by 7 Comments

One of our favorite retro hardware enthusiasts, [CuriousMarc], is back with the outstanding tale of preserving Apollo Program software, and building a core rope reader from scratch to do it. We’ve talked about [Marc]’s previous efforts to get real Apollo hardware working again, and one of the by-products of this effort was recovering the contents of the read-only core rope memory modules that were part of that hardware.

The time finally came to hand the now-working Apollo guidance computer back to its owner, which left the team without any hardware to read core rope modules. But the archive of software from the program was still incomplete, and there were more modules to try to recover. So, the wizardly [Mike Stewart] just decided to roll up his sleeves and build his own reader. Which didn’t actually work as expected the first time.

And this leads us into one of [Marc]’s elevator music explainers, where he gives a beautiful rundown on how core rope works. And if you are thinking of core memory based on ferrite cores, get ready for a brain stretch, as core rope is quite a bit different, and is even more complicated to read. Which brings us to the bug in [Mike]’s reader, which is actually a bug in the block II design of the core rope modules.

Reading a byte off the module requires setting multiple inhibit wires to select an individual core. An innovation in block II allowed those inhibit wires to run at half current, but it turns out that didn’t actually work as intended, and partially selected multiple cores on the other half of the module. And [Mike] forget to re-implement that bug — the reader needs to literally be bug-for-bug compatible. A quick recompile of the FPGA code makes everything work again. And the conservation effort can continue. Stay tuned for more in the Apollo story!

Continue reading “Saving Apollo By Decoding Core Rope” →

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

November 3, 2023 by 4 Comments

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” →

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

October 27, 2023 by 12 Comments

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!

October 20, 2023 by 5 Comments

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

October 13, 2023 by 17 Comments

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” →

Meshtastic And Owntracks To Kick Your Google Habit

October 11, 2023 by 20 Comments

I have an admission to make. I have a Google addiction. Not the normal addiction — I have a problem with Google Maps, and the timeline feature. I know, I’m giving my location data to Google, who does who-knows-what-all with it. But it’s convenient to have an easy way to share location with my wife, and very useful to track my business related travel for each month. What we could really use is a self-hosted, open source system to track locations and display location history. And for bonus points, let’s include some extra features, like the ability to track vehicles, kids, and pets that aren’t carrying a dedicated Internet connection.

You can read the title — you know where we’re going with this. We’re setting up an Owntracks service, and then tying it to Meshtastic for off-Internet usability. The backbone that makes this work is MQTT, a network message bus that has really found its niche in the Home Assistant project among others. It’s a simple protocol, where clients send brief messages labeled by topic, and can also subscribe to specific topics. For this little endeavor we’ll use the Mosquito MQTT broker.

One of the nice things about MQTT is that the messages are all text strings, and often take the form of JSON. When trying to get two applications to talking using a shared MQTT server, there may need to be a bit of translation. One application may label a field latitude, and the other shortens it to lat. The glue code to put these together is often known as an MQTT translator, or sometimes an MQTT bridge. This is a program that listens to a given topic, ingests each message, and sends it back to the MQTT server in a different format and topic name.

The last piece is Owntracks, which has a recorder project, which pulls locations from the MQTT server, and stores it locally. Then there’s Owntracks Frontend, which is a much nicer user interface, with some nice features like viewing movement a day at a time. Continue reading “Meshtastic And Owntracks To Kick Your Google Habit” →

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

October 6, 2023 by 8 Comments

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” →