FLOSS Weekly Episode 784: I’ll Buy You A Poutine

This week Jonathan Bennett and Dan Lynch talk with François Proulx about Poutine, the Open Source security scanner for build pipeline vulnerabilities. This class of vulnerability isn’t as well known as it should be, and threatens to steal secrets, or even allow for supply chain attacks in FLOSS software.

Poutine does a scan over an organization or individual repository, looking specifically for pipeline issues. It runs on both GitHub and GitLab, with more to come!

Continue reading “FLOSS Weekly Episode 784: I’ll Buy You A Poutine”

This Week In Security: TunnelVision, Scarecrows, And Poutine

There’s a clever “new” attack against VPNs, called TunnelVision, done by researchers at Leviathan Security. To explain why we put “new” in quotation marks, I’ll just share my note-to-self on this one written before reading the write-up: “Doesn’t using a more specific DHCP route do this already?” And indeed, that’s the secret here: in routing, the more specific route wins. I could not have told you that DHCP option 121 is used to set extra static routes, so that part was new to me. So let’s break this down a bit, for those that haven’t spent the last 20 years thinking about DHCP, networking, and VPNs.

So up first, a route is a collection of values that instruct your computer how to reach a given IP address, and the set of routes on a computer is the routing table. On one of my machines, the (slightly simplified) routing table looks like:

# ip route
default via 10.0.1.1 dev eth0
10.0.1.0/24 dev eth0

The first line there is the default route, where “default” is a short-hand for 0.0.0.0/0. That indicate a network using the Classless Inter-Domain Routing (CIDR) notation. When the Internet was first developed, it was segmented into networks using network classes A, B, and C. The problem there was that the world was limited to just over 2.1 million networks on the Internet, which has since proven to be not nearly enough. CIDR came along, eliminated the classes, and gave us subnets instead.

In CIDR notation, the value after the slash is commonly called the netmask, and indicates the number of bits that are dedicated to the network identifier, and how many bits are dedicated to the address on the network. Put more simply, the bigger the number after the slash, the fewer usable IP addresses on the network. In the context of a route, the IP address here is going to refer to a network identifier, and the whole CIDR string identifies that network and its size.

Back to my routing table, the two routes are a bit different. The first one uses the “via” term to indicate we use a gateway to reach the indicated network. That doesn’t make any sense on its own, as the 10.0.1.1 address is on the 0.0.0.0/0 network. The second route saves the day, indicating that the 10.0.1.0/24 network is directly reachable out the eth0 device. This works because the more specific route — the one with the bigger netmask value, takes precedence.

The next piece to understand is DHCP, the Dynamic Host Configuration Protocol. That’s the way most machines get an IP address from the local network. DHCP not only assigns IP addresses, but it also sets additional information via numeric options. Option 1 is the subnet mask, option 6 advertises DNS servers, and option 3 sets the local router IP. That router is then generally used to construct the default route on the connecting machine — 0.0.0.0/0 via router_IP.

Remember the problem with the gateway IP address belonging to the default network? There’s a similar issue with VPNs. If you want all traffic to flow over the VPN device, tun0, how does the VPN traffic get routed across the Internet to the VPN server? And how does the VPN deal with the existence of the default route set by DHCP? By leaving those routes in place, and adding more specific routes. That’s usually 0.0.0.0/1 and 128.0.0.0/1, neatly slicing the entire Internet into two networks, and routing both through the VPN. These routes are more specific than the default route, but leave the router-provided routes in place to keep the VPN itself online.

And now enter TunnelVision. The key here is DHCP option 121, which sets additional CIDR notation routes. The very same trick a VPN uses to override the network’s default route can be used against it. Yep, DHCP can simply inform a client that networks 0.0.0.0/2, 64.0.0.0/2, 128.0.0.0/2, and 192.0.0.0/2 are routed through malicious_IP. You’d see it if you actually checked your routing table, but how often does anybody do that, when not working a problem?

There is a CVE assigned, CVE-2024-3661, but there’s an interesting question raised: Is this a vulnerability, and in which component? And what’s the right solution? To the first question, everything is basically working the way it is supposed to. The flaw is that some VPNs make the assumption that a /1 route is a bulletproof way to override the default route. The solution is a bit trickier. Continue reading “This Week In Security: TunnelVision, Scarecrows, And Poutine”

Screenshot of the GitHub Marketplace action listing, describing the extension

Giving Your KiCad PCB Repository Pretty Pictures

Publishing your boards on GitHub or GitLab is a must, and leads to wonderful outcomes in the hacker world. On their own, however, your board files might have the repo look a bit barren; having a picture or two in the README is the best. Making them yourself takes time – what if you could have it happen automatically? Enter kicad-render, a GitHub and GitLab integration for rendering your KiCad projects by [linalinn].

This integration makes your board pictures, top and bottom view, generated on every push into the repo – just embed two image links into your README.md. This integration is made possible thanks to the new option in KiCad 8’s kicad-cli – board image generation, and [linalinn]’s code makes KiCad run on GitHub/GitLab servers.

For even more bling, you can enable an option to generate a GIF that rotates your board, in the style of that one [arturo182] demo – in fact, this integration’s GIF code was borrowed from that script! Got a repository with many boards in one? There’s an option you could make work for yourself, too.

All you need to do is to follow a couple of simple steps; [linalinn] has documented both the GitHub and GitLab integration. We’ve recently talked about KiCad integrations in more detail, if you’re wondering what else your repository could be doing!

Dump A Code Repository As A Text File, For Easier Sharing With Chatbots

Some LLMs (Large Language Models) can act as useful programming assistants when provided with a project’s source code, but experimenting with this can get a little tricky if the chatbot has no way to download from the internet. In such cases, the code must be provided by either pasting it into the prompt or uploading a file manually. That’s acceptable for simple things, but for more complex projects, it gets awkward quickly.

To make this easier, [Eric Hartford] created github2file, a Python script that outputs a single text file containing the combined source code of a specified repository. This text file can be uploaded (or its contents pasted into the prompt) making it much easier to share code with chatbots.

Continue reading “Dump A Code Repository As A Text File, For Easier Sharing With Chatbots”

“Cheap Yellow Display” Builds Community Through Hardware

For the most part, Hackaday is all about hardware hacking projects. Sometimes, though, the real hack in a project isn’t building hardware, but rather building a community around the hardware.

Case in point: [Brian Lough]’s latest project, which he dubs “CYD,” for the “cheap yellow display” that it’s based on; which is a lot easier to remember than its official designation, ESP32-2432S028R. Whatever you call it, this board is better than it sounds, with an ESP32 with WiFi, Bluetooth, a 320×480 resistive touch screen, and niceties like USB and an SD card socket — all on aforementioned yellow PCB. The good news is that you can get this thing for about $15 on Ali Express. The bad news is that, as is often the case with hardware from the Big Rock Candy Mountain, the only documentation available comes from a website we wouldn’t touch with a ten-foot pole.

To fix this problem, [Brian] started what he hopes will be a collaborative effort to build a knowledge base for the CYD, to encourage people to put these little gems to work. He has already kick-started that with a ton of quality documentation, including setup and configuration instructions, tips and gotchas, and some sample projects that put the CYD’s capabilities to the test. It’s all on GitHub and there’s already at least one pull request; hopefully that’ll grow once the word gets out.

Honestly, these look like fantastic little boards that are a heck of a bargain. We’re thinking about picking up a few of these while they last, and maybe even getting in on the action in this nascent community. And hats off to [Brian] for getting this effort going.

Continue reading ““Cheap Yellow Display” Builds Community Through Hardware”

The GitHub Silverware Drawer Dilemma, Or: Finding Active Repository Forks

An fortunate reality of GitHub and similar sites is that projects that are abandoned by the maintainer are often continued by someone else who forked the project. Unfortunately, the ease of forking also means that GitHub projects tend to have a lot of forks, with the popular projects having hundreds of them. Since GitHub has elected to not provide a way to filter or sort these forks, finding the most active fork can be rather harrowing.

In addition, a popular project’s dead repository tends to score higher in search results than replacement forks. For these particular situations a couple of very useful websites and browser add-ons have been developed. The Lovely Forks add-on by [Utkarsh Upadhyay] seeks to insert information on forks that are notable or newer than the repository one is looking at.

Meanwhile, the Active Forks project by [Samar Dhwoj Acharya] provides a sortable list of project forks when provided with a GitHub repository name. This helps enormously when trying to find the freshest forks in a whole list. This is similar to the Useful Forks project that provides a web-based interface in addition to a Chrome extension. Do note that these queries will count towards the GitHub API rate-limits, so you may need to add an access token.

It’s a shame that GitHub doesn’t offer such functionality by default, but thanks to these projects the times of clicking through a hundred forks to find the freshest one is at least over. For now.

Push ESP32 Over The Air Updates From GitHub

Let’s say you’re working on an ESP32 project to send off to your grandma; something she can just plug in and it will start automatically monitoring her plant’s water levels. But you discover a critical flaw in the firmware and need to update it. Does she send it back? Do you walk her through dropping the update via the Arduino IDE OTA? The easiest way would be to plan and use something like esp_ghota, an OTA framework by [Justin Hammond].

OTA (Over-The-Air) updates are a fantastic feature of the ESP32, and we’ve covered libraries that make it easy. But compared to those earlier projects, esp_ghota takes a different approach. Rather than hosting a web server where someone can drop a binary, it looks at GitHub releases. [Justin] had to include a streaming JSON parser, as GitHub API responses tend to be beefy. The workflow is straightforward, push a new commit to your main branch on GitHub, and the action will trigger, building a few different versions. Your little plant watering reminder at your grandma’s will check every so often to see if a new version has been pushed and can update with rollback on littlefs, fatfs, and spiffs filesystems.

It’s an incredible project that we suspect will be very useful for many folks to update their projects. [Justin] even includes an example GitHub action and a sample ESP32 project.