Garage Door Opener Ejection Seat

November 5, 2022 by Jonathan Bennett 16 Comments

[Scott Prints] had a familiar problem. His garage door opener was boring, and rattled around annoyingly in his car’s center console. This was obviously a major issue that needed to be dealt with. His solution was to install an ejector seat. Er, well, an ejector seat button. At least, that’s what it’s labeled. (That’s sure to be a great conversation starter for passengers.)

The end result looks slick and combines several build techniques. He started by taking measurements and 3D-printing a test piece for the center console nook. Turns out, that’s a more complicated shape than it seems. Rather than try to measure the exact angles and radii, Scott turned to the tried-and-true method of fiddling with the parameters and printing a second test. Close enough.

The coolest and most challenging element of the build was engraving and cutting the aluminum plate that forms the visible part of the build. Turns out, the online recommendations for milling aluminum are laughably optimistic when you don’t have an industrial CNC machine. Slower, shallower cuts got the job done, albeit slowly. A red paint-filled marker made the letters pop. The guts of the donor garage door opener are fitted into a 3d-printed shell, and then a Big Red Button threads into the print, holding the whole build together. A bit of solder later, and the project is done. Simple, effective, and very stylish! We approve. Come back after the break for the build video.
Continue reading “Garage Door Opener Ejection Seat” →

This Week In Security: OpenSSL Fizzle, Java XML, And Nothing As It Seems

November 4, 2022 by Jonathan Bennett 3 Comments

The security world held our collective breaths early this week for the big OpenSSL vulnerability announcement. Turns out it’s two separate issues, both related to punycode handling, and they’ve been downgraded to high severity instead of critical. Punycode, by the way, is the system for using non-ASCII Unicode characters in domain names. The first vulnerability, CVE-2022-3602, is a buffer overflow that writes four arbitrary bytes to the stack. Notably, the vulnerable code is only run after a certificate’s chain is verified. A malicious certificate would need to be either properly signed by a Certificate Authority, or manually trusted without a valid signature.

A couple sources have worked out the details of this vulnerability. It’s an off-by-one error in a loop, where the buffer length is checked earlier in the loop than the length variable is incremented. Because of the logic slip, the loop can potentially run one too many times. That loop processes the Unicode characters, encoded at the end of the punycode string, and injects them in the proper place, sliding the rest of the string over a byte in memory as a result. If the total output length is 513 characters, that’s a single character overflow. A Unicode character takes up four bytes, so there’s your four-byte overflow. Continue reading “This Week In Security: OpenSSL Fizzle, Java XML, And Nothing As It Seems” →

This Week In Security: IOS, OpenSSL, And SQLite

October 28, 2022 by Jonathan Bennett 13 Comments

Earlier this week, a new release of iOS rolled out, fixing a handful of security issues. One in particular noted it “may have been actively exploited”, and was reported anonymously. This usually means that a vulnerability was discovered in the wild, being used as part of an active campaign. The anonymous credit is interesting, too. An educated guess says that this was a rather targeted attack, and the security company that found it doesn’t want to give away too much information.

Of other interest is the GPU-related fix, credited to [Asahi Lina], the VTuber doing work on porting Linux to the Apple M1/M2 platform, and particularly focusing on GPU drivers. She’s an interesting case, and doing some very impressive work. There does remain the unanswered question of how the Linux Kernel will deal with a pull request coming from a pseudonym. Regardless, get your iOS devices updated.

Continue reading “This Week In Security: IOS, OpenSSL, And SQLite” →

This Week In Security: Linux WiFi, Fortinet, Text4Shell, And Predictable GUIDs

October 21, 2022 by Jonathan Bennett 18 Comments

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. Continue reading “This Week In Security: Linux WiFi, Fortinet, Text4Shell, And Predictable GUIDs” →

This Week In Security: Npm Timing Leak, Siemens Universal Key, And PHP In PNG

October 14, 2022 by Jonathan Bennett 12 Comments

First up is some clever wizardry from the [Aqua Nautilus] research team, who discovered a timing attack that leaks information about private npm packages. The setup is this, npm hosts both public and private node.js packages. The public ones are available to everyone, but the private packages are “scoped”, meaning they live within a private namespace, “@owner/packagename” and are inaccessible to the general public. Trying to access the package results in an HTTP 404 error — the same error as trying to pull a package that doesn’t exist.

The clever bit is to keep trying, and really pay attention to the responses. Use npm’s API to request info on your target package, five times in a row. If the package name isn’t in use, all five requests will take the expected amount of time. That request lands at the service’s backend, a lookup is performed, and you get the response. On the flipside if your target package does exist, but is privately scoped, the first request returns with the expected delay, and the other four requests return immediately. It appears that npm has front-end that can cache a 404 response for a private package. That response time discrepancy means you can map out the private package names used by a given organization in their private scope.

Now this is all very interesting, but it turns into a plausible attack when combined with typosquatting and dependency confusion issues. Those attacks are two approaches to the same goal, get a node.js deployment to run a malicious package instead of the legitimate one the developer intended. One depends on typos, but dependency confusion just relies on a developer not explicitly defining the scope of a package.

Continue reading “This Week In Security: Npm Timing Leak, Siemens Universal Key, And PHP In PNG” →

This Week In Security: PHP Attack Defused, Scoreboard Manipulation, And Tillitis

October 7, 2022 by Jonathan Bennett 1 Comment

If you use PHP, you likely use the Composer tool for managing dependencies, at least indirectly. And the good folks at SonarSource found a nasty, potential supply chain attack in this tool, when used in the Packagist repository. The problem is the support for arbitrary README filenames. When a package update shows up on Packagist, that service uses a Version Control Service (VCS) like Git or Mercurial to pull the specified readme location. That pull operation is subject to argument injection. Name your branch --help, and Git will happily run the help argument instead of doing the pull intended. In the case of Git commands, our intrepid researchers were unable to weaponize the issue to achieve code execution.

Composer also supports projects that use Mercurial as their VCS, and Mercurial has a --config option that has… interesting potential. It allows redefining a Mecurial command as a script snippet. So a project just has to contain a malicious payload.sh, and the readme set to --config=alias.cat=!hg cat -r : payload.sh|sh;,txt. For those keeping track at home, the vulnerability is that this cursed string of ugly is accepted by Composer as a valid filename. This uses the --config trick to redefine cat as a bit of script that executes the payload. It ends in .txt because that is a requirement of Composer.

So let’s talk about what this little hack could have been used for, or maybe still used for on an unpatched, private install of Packagist. This is an unattended attack that jumps straight to remote script execution — on an official package repository. If discovered and used for evil, this would have been a massive supply chain attack against PHP deployments. Instead, thanks to SonarSource, it was discovered and disclosed privately back in April. The official Packagist repo at packagist.org was fixed the day after disclosure, and a CVE and updated packages went out six days later. Great work all around.
Continue reading “This Week In Security: PHP Attack Defused, Scoreboard Manipulation, And Tillitis” →

2022 Cyberdeck Contest: The Oscilloscope Deck

September 30, 2022 by Jonathan Bennett 27 Comments

When [Jak_o_Shadows] Siglent Oscilloscope died, he didn’t just mourn the loss, he saw an opportunity. See, he had a Raspberry Pi 400 already set aside for a cyberdeck build, and he just scored a novel case. Most of the insides of the old scope came out, but the screen and control knobs live on in the new build. An HDMI-to-LVDS adapter brought the screen back to life, and the control knobs are a work-in-progress. Added to the case are some fun goodies, like a LimeSDR, connected to the old scope inputs. A PL2303 is wired to the serial port, making that functional, too. It’s a very nice touch that the build retains the original scope’s functions this way.

There’s plenty of 3d-printed goodness, like some internal brackets to hold things in place. The real star of the show is a 3d-printed hinge, holding the scope and Pi 400 together and making the whole package portable. There’s a neat tip, too, in that the Pi 400 has a huge integrated heat sync under the keyboard. It’s just a sheet of metal, so you can drill and tap it as mounting points. Cool!

This is a nifty build, and certainly a worthy deck for jacking-in to whatever you’re working on. And re-purposing an oscilloscope is a nice aesthetic. If [Jak_o_Shadows] can just get the front array of buttons and knobs working with his STM32, this will be a killer deck, the envy of console cowboys everywhere.