First up, git has been audited. This was an effort sponsored by the Open Source Technology Improvement Fund (OSTIF), a non-profit working to improve the security of Open Source projects. The audit itself was done by researchers from X41 and GitLab, and two critical vulnerabilities were found, both caused by the same bad coding habit — using an
int to hold buffer lengths.
On modern systems, a
size_t is always unsigned, and the same bit length as the architecture bit-width. This is the proper data type for string and buffer lengths, as it is guaranteed not to overflow when handling lengths up to the maximum addressable memory on the system. On the other hand, an
int is usually four bytes long and signed, with a maximum value of 2^31-1, or 2147483647 — about 2 GB. A big buffer, but not an unheard amount of data. Throw something that large at git, and it will break in unexpected ways.
Our first example is CVE-2022-23521, an out of bounds write caused by an
int overflowing to negative. A
.gitattributes file can be committed to a repository with a modified git client, and then checking out that repository will cause the
num_attrs variable to overflow. Push the overflow all the way around to a small negative number, and git will then vastly under-allocate the attributes buffer, and write all that data past the end of the allocated buffer.
CVE-2022-41903 is another signed integer overflow, this time when a pretty print format gets abused to do something unexpected. Take a look at this block of code:
Continue reading “This Week In Security: Git Deep Dive, Mailchimp, And SPF” →
Wouldn’t it be great if you could keep all of your small Internet-connected hacks up to date with a single codebase? A couple of weeks ago, we wrote up a project that automagically pulls down OTA updates to an ESP32 from GitHub, using the ESP32 C SDK. [Pascal] asked in the comments, “but what about MicroPython?” Gauntlet thrown, [TURFPTAx] wrote
ugit.py – a simple library that mirrors all of the code from a public GitHub Python repo straight to your gizmo running Micropython.
[Damped] wrote in about Senko, another library that does something very similar, but by then [TURFPTAx] was already done. Bam! Part of the speed is that MicroPython includes everything you need to get the job done – parsing streamed JSON was the hard part with the original hack. MicroPython makes those sorts of things easy.
This is one of those ideas that’s just brilliant for a hacker with a small flock of independent devices to herd. And because
ugit.py itself is fairly simple and readable, if you need to customize it to do your own bidding, that’s no problem either. Just be sure that when you’re storing your WiFi authentication info, it’s not publicly displayed. ([TURFPTAx], could I log into your home WiFi?)
What’s [TURFPTAx] going to be using this for? We’re guessing it’s going to be deploying code to his awesome Open Muscle sensing rigs. What will we be using it for? Blinky Christmas decorations for the in-laws, now remotely updatable without them having to even learn what a “repo” is.
Continue reading “GitHub ESP32 OTA Updates, Now In MicroPython Flavor” →
Last time, I’ve shown you how to create a local Git repository around your PCB project. That alone provides you with local backups, helping you never lose the changes you make to your files, and always be able to review the history of your project as it developed.
However, an even more significant part of Git’s usefulness is the ability to upload our creations to one of the various online Git repository hosting services, and keep it up to date at all times with a single shell command. I’d like to show you how to upload your project to GitHub and GitLab, in particular!
Continue reading “Git Your PCBs Online” →
Git is a wonderful tool that can multiply your project’s impact, or make your project easier to manage by an order of magnitude. Some of us hackers don’t yet know how to use command-line Git, but a relatable example of why a certain tool would be useful might be a good start. Today, I’d like to give you a Git crash course – showing you why and how to put a KiCad PCB into a Git repository, later to be shared with the world.
KiCad works wonderfully with Git. The schematic and PCB files of KiCad are human-readable, especially when compared to other PCB file formats. KiCad creates different files for different purposes, each of them with a well-defined role, and you can make sense of every file in your project folder. What’s more, you can even modify KiCad files in a text editor! This is exactly the kind of use case that Git fits like a glove.
Not Just For Software Developers
What’s Git about, then? Fundamentally, Git is a tool that helps you keep track of code changes in a project, and share these changes with each other. Intended for Linux kernel development as its first target, this is what it’s been designed for, but it’s flexibility extends far beyond software projects. We hardware hackers can make use of it in a variety of ways – we can store PCB and other design software files, blog articles, project documentation, personal notes, configuration files and whatever else that even vaguely fits the Git modus operandi. Continue reading “Git Intro For Hardware Hackers” →
You can’t do much development without running into Git, the version control management system. Part of that is because so much code lives on GitHub which uses Git, although you don’t need to know anything about that if all you want to do is download code. [Dr. Torq] has a good primer on using Git with the Arduino IDE, if you need to get your toes wet.
You might think if you develop by yourself you don’t need something like Git. However, using a version control system is a great convenience, especially if you use it correctly. There’s a bug out in the field? What version of the firmware? You can immediately get a copy of the source code at that point in time using Git. A feature is broken? It is very easy to see exactly what changed. So even if you don’t work in a team, there are advantages to having source code under control.
Continue reading “Arduino And Git: Two Views” →
OpenSSH has minted their 9.0 release, and it includes a pair of security changes. Unlike most of the releases we cover here, this one has security hardening to prevent issues, not emergency fixes for current ones. First up, the venerable scp/rcp protocol has been removed. Your
scp commands will now use SFTP under the hood. The more interesting security change is the new default key exchange, the NTRU algorithm. NTRU is thought to be quantum-hard.
Continue reading “This Week In Security: OpenSSH, Git, And Sort-of NGINX 0-day” →
Back in January, we covered the news that Ubiquiti had a breach of undisclosed severity. One reader pointed out the compromise of a handful of devices as potentially related. With no similar reports out there, I didn’t think too much of it at the time. Now, however, a whistleblower from Ubiquiti has given Krebs the juicy details.
The “third party cloud provider” the original disclosure referred to was Amazon Web Services (AWS). According to the whistleblower, just about everything was accessible, including the keys to log in to any Ubiquiti device on the internet, so long as it was cloud enabled. The attackers installed a couple of backdoors in Ubiquiti’s infrastructure, and sent a 50 bitcoin blackmail threat. To their credit, Ubiquiti ignored the blackmail and cleaned up the mess.
To the claim that there was no evidence attackers had accessed user accounts, it seems that the database in question simply has no logging enabled. There was no evidence, because nothing was watching. So far, I’ve only seen the one report of device compromise that was potentially a result of the attack. If you had a Ubiquiti device go rogue around December 2020 – January 2021, be sure to let us know. Continue reading “This Week In Security: Ubiquity Update, PHP Backdoor, And Netmask” →