Author: Jonathan Bennett

543 Articles

This Week In Security: For The Horde, Feature Not A Bug, And Confluence

June 10, 2022 by 7 Comments

If you roll way back through the history of open source webmail projects, you’ll find Horde, a groupware web application. First released in 1998 on Freshmeat, it gained some notoriety in early 2012 when it was discovered that the 3.0 release had been tampered with, and packages containing a backdoor had been shipped for three months. While this time around it isn’t an intentional backdoor, there is a very serious problem in the Horde webmail interface. Or more accurately, a pair of problems. The most serious is CVE-2022-30287, an RCE bug allowing an authenticated user to trigger code execution on the connected server.

The vulnerable element is the Turba address book module, which uses a PHP factory method to access a specific address book. The create() method has an interesting bit of code, that first checks the initialization value. If it’s a string, that value is understood as the name of the local address book to access. However, if the factory is initialized with an array, any of the address book drivers can be used, including the IMSP driver. IMSP fetches serialized data from remote servers, and deserializes it. And yes, PHP can have deserialization bugs, and this one runs code on the host.

But it’s not that bad, it’s only authenticated users, right? That would be bad enough, but that second bug is a Cross-site Request Forgery, CSRF, triggered by viewing an email. So on a vulnerable Horde server, any user viewing a malicious message would trigger RCE on the server. Oof. So let’s talk fixes. There is a new version of the Turba module that seems to fix the bugs, but it’s not clear that the actual Horde suite has pushed an update that includes it. So you may be on your own. As is pointed out on the Sonar Blog where the vulnerability was discovered, Horde itself seems to be essentially unmaintained at this point. Maybe time to consider migrating to a newer platform.
Continue reading “This Week In Security: For The Horde, Feature Not A Bug, And Confluence” →

This Week In Security: Follina, Open Redirect RCE, And Annoyware

June 3, 2022 by 1 Comment

Depending on who you ask, there’s either 2 vulnerabilities at play in Follina, only one, or according to Microsoft a week ago, no security problem whatsoever. On the 27th of last month, a .docx file was uploaded to VirusTotal, and most of the tools there thought it was perfectly normal. That didn’t seem right to [@nao_sec], who raised the alarm on Twitter. It seems this suspicious file originated somewhere in Belarus, and it uses a series of tricks to run a malicious PowerShell script.
Continue reading “This Week In Security: Follina, Open Redirect RCE, And Annoyware” →

This Week In Security: Good Faith, Easy Forgery, And I18N

May 27, 2022 by 26 Comments

There’s a danger in security research that we’ve discussed a few times before. If you discover a security vulnerability on a production system, and there’s no bug bounty, you’ve likely broken a handful of computer laws. Turn over the flaw you’ve found, and you’re most likely to get a “thank you”, but there’s a tiny chance that you’ll get charged for a computer crime instead. Security research in the US is just a little safer now, as the US Department of Justice has issued a new policy stating that “good-faith security research should not be charged.”

While this is a welcome infection of good sense, it would be even better for such a protection to be codified into law. The other caveat is that this policy only applies to federal cases in the US. Other nations, or even individual states, are free to bring charges. So while this is good news, continue to be careful. There are also some caveats about what counts as good-faith — If a researcher uses a flaw discovery to extort, it’s not good-faith.
Continue reading “This Week In Security: Good Faith, Easy Forgery, And I18N” →

This Week In Security: IPhone Unpowered, Python Unsandboxed, And Wizard Spider Unmasked

May 20, 2022 by 14 Comments

As conspiracy theories go, one of the more plausible is that a cell phone could be running malicious firmware on its baseband processor, and be listening and transmitting data even when powered off. Nowadays, this sort of behavior is called a feature, at least if your phone is made by Apple, with their Find My functionality. Even with the phone off, the Bluetooth chip runs happily in a low-power state, making these features work. The problem is that this chip doesn’t do signed firmware. All it takes is root-level access to the phone’s primary OS to load a potentially malicious firmware image to the Bluetooth chip.

Researchers at TU Darmstadt in Germany demonstrated the approach, writing up a great paper on their work (PDF). There are a few really interesting possibilities this research suggests. The simplest is hijacking Apple’s Find My system to track someone with a powered down phone. The greater danger is that this could be used to keep surveillance malware on a device even through power cycles. Devices tend to be secured reasonably well against attacks from the outside network, and hardly at all from attacks originating on the chips themselves. Unfortunately, since unsigned firmware is a hardware limitation, a security update can’t do much to mitigate this, other than the normal efforts to prevent attackers compromising the OS.
Continue reading “This Week In Security: IPhone Unpowered, Python Unsandboxed, And Wizard Spider Unmasked” →

Things Are Getting Rusty In Kernel Land

May 17, 2022 by 163 Comments

There is gathering momentum around the idea of adding Rust to the Linux kernel. Why exactly is that a big deal, and what does this mean for the rest of us? The Linux kernel has been just C and assembly for its entire lifetime. A big project like the kernel has a great deal of shared tooling around making its languages work, so adding another one is quite an undertaking. There’s also the project culture developed around the language choice. So why exactly are the grey-beards of kernel development even entertaining the idea of adding Rust? To answer in a single line, it’s because C was designed in 1971, to run on the minicomputers at Bell Labs. If you want to shoot yourself in the foot, C will hand you the loaded firearm.

On the other hand, if you want to write a kernel, C is a great language for doing low-level coding. Direct memory access? Yep. Inline assembly? Sure. Runs directly on the metal, with no garbage collection or virtual machines in the way? Absolutely. But all the things that make C great for kernel programming also make C dangerous for kernel programming.

Now I hear your collective keyboards clacking in consternation: “It’s possible to write safe C code!” Yes, yes it is possible. It’s just very easy to mess up, and when you mess up in a kernel, you have security vulnerabilities. There’s also some things that are objectively terrible about C, like undefined behavior. C compilers do their best to do the right thing with cursed code like i++ + i++; or a[i] = i++;. But that’s almost certainly not going to do what you want it to, and even worse, it may sometimes do the right thing.

Rust seems to be gaining popularity. There are some ambitious projects out there, like rewriting coreutils in Rust. Many other standard applications are getting a Rust rewrite. It’s fairly inevitable that the collection of Rust developers started to ask, could we invade the kernel next? This was pitched for a Linux Plumbers Conference, and the mailing list response was cautiously optimistic. If Rust could be added without breaking things, and without losing the very things that makes Rust useful, then yes it would be interesting. Continue reading “Things Are Getting Rusty In Kernel Land” →

Asahi GPU Hacking

May 16, 2022 by 7 Comments

[Alyssa Rosenzweig] has been tirelessly working on reverse engineering the GPU built into Apple’s M1 architecture as part of the Asahi Linux effort. If you’re not familiar, that’s the project adding support to the Linux kernel and userspace for the Apple M1 line of products. She has made great progress, and even got primitive rendering working with her own open source code, just over a year ago.

Trying to mature the driver, however, has hit a snag. For complex rendering, something in the GPU breaks, and the frame is simply missing chunks of content. Some clever testing discovered the exact failure trigger — too much total vertex data. Put simply, it’s “the number of vertices (geometry complexity) times amount of data per vertex (‘shading’ complexity).” That… almost sounds like a buffer filling up, but on the GPU itself. This isn’t a buffer that the driver directly interacts with, so all of this sleuthing has to be done blindly. The Apple driver doesn’t have corrupted renders like this, so what’s going on?
Continue reading “Asahi GPU Hacking” →

This Week In Security: F5 Twitter PoC, Certifried, And Cloudflare Pages Pwned

May 13, 2022 by 7 Comments

F5’s BIG-IP platform has a Remote Code Execution (RCE) vulnerability: CVE-2022-1388. This one is interesting, because a Proof of Concept (PoC) was quickly reverse engineered from the patch and released on Twitter, among other places.

HORIZON3.ai researcher [James Horseman] wrote an explainer that sums up the issue nicely. User authentication is handled by multiple layers, one being a Pluggable Authentication Modules (PAM) module, and the other internally in a Java class. In practice this means that if the PAM module sees an X-F5-Auth-Token, it passes the request on to the Java code, which then validates the token to confirm it as authentic. If a request arrives at the Java service without this header, and instead the X-Forwarded-Host header is set to localhost, the request is accepted without authentication. The F5 authentication scheme isn’t naive, and a request without the X-F5-Auth-Token header gets checked by PAM, and dropped if the authentication doesn’t check out.

So where is the wiggle room that allows for a bypass? Yet another HTTP header, the Connection header. Normally this one only comes in two varieties, Connection: close and Connection: keep-alive. Really, this header is a hint describing the connection between the client and the edge proxy, and the contents of the Connection header is the list of other headers to be removed by a proxy. It’s essentially the list of headers that only apply to the connection over the internet. Continue reading “This Week In Security: F5 Twitter PoC, Certifried, And Cloudflare Pages Pwned” →