magmastonealex

I sort of accidentally stumbled into it when I joined an (at the time) startup as they were just getting into the market. So I don't know that I have anything specific to offer :)

I don't want to name names for companies in the industry, but you can find them in industry publications like Traffic Technology Today, or often as contributors to the standards documents like NTCIP 1202, ITE ATC 5301, etc.

I will say that there are a number of long-standing (40+ years) companies in the industry that seem to still operate the "legacy" way - slow iterations, very small software team, seemingly not much desire for large change. Basically, a hardware company that also happens to sell software.

There are also newer entrants to the market in the past ~decade or so that operate a lot closer to a modern software company - lots of new features coming out, fast-moving software teams, etc.

(again, all opinions are my own here.)

Unfortunately those fears are well-founded.

The majority of MMUs on the market that I have had a close look at implement safety-critical functionality on a microcontroller with updatable firmware. Some can even be updated over IP. I haven't had the opportunity to dig into if those firmware upgrades are signed or otherwise integrity-protected.

The standard unfortunately does not specify a functional safety standard or other measures to ensure absolute safety.

In theory it would be possible to implement it in discrete logic (or an FPGA or other formally-verifiable process), but as far as I know no manufacturer has done so (I'd love to be wrong!)

Well, the "locked" cabinet generally uses the same key everywhere in North America, which isn't a great start :)

A number of agencies put these controllers directly on the Internet (a search on Shodan for some telltale strings produces concerning numbers of hits).

Others will use one giant flat network across their entire city - so if you get access at once location, you have access to the entire network. This could mean accessing a "rural" or quiet location, but then actually attacking a much busier one.

Now you start to get into the differences between the various standards :)

In NEMA TS2 (and the more modern ITE ATC), the MMU does enforce a yellow clearance time - you need the light to turn yellow for a period of time before a conflicting phase goes green. Usually this is a few seconds. Changing phases rapidly would likely confuse drivers, but in _theory_ shouldn't cause a collision if people respect yellows.

(believe it or not, in some localities a "red clearance" time - all red - is not required and lights will go from yellow in one direction to green in another.)

In CalTrans TEES, I do not believe the standard calls for the MMU to enforce clearance times - the attack you describe would potentially be possible.

Generally no, this is something from fiction.

I'm mostly familiar with North American traffic signal control, and in those traffic cabinets there is a device known as an "MMU" (Malfuction Management Unit) which acts as a safety monitor for the rest of the traffic cabinet.

That device will catch so-called "conflicts" (two conflicting directions green at the same time) and put the intersection into a fail-safe state (usually flashing red/yellow lights).

There are of course some edge cases where this is technically possible (as long as the cabinet door is open in CalTrans TEES cabinets, you can actually remove the MMU entirely and do whatever you want), and I'm not familiar with safety mechanisms used in other localities.

(Note: I work in the industry, not for any of the companies in this article, and my views are my own).

There is a revocation system in place (the RevokedKeys directive in the sshd configuration file, which seems to be system-wide rather than configured at the user-level. At least, that’s the only way I’ve used it)

I agree with the sentiment though, it is far less extensive than traditional X.509 certificate infrastructure.

C compiled down to eBPF (as implemented with the Linux kernel) is not turing-complete. eBPF has a wide variety of uses from network filtering to hooking into certain syscalls.

The bytecode is theoretically turing-complete, but the verifier present in the kernel ensures that the code contains no loops and accesses no out-of-bounds memory.

With `clang`, you can compile C down to eBPF bytecode. It's a subset of C, with a lot of restrictions, but it is familiar and capable of some remarkable things past just simple packet parsing & filtering.

I'm curious how you'd propose doing that.

If I give you a buffer of 5 bytes:

[0x68 0x65 0x6c 0x6c 0x6f]

there are a ton of ways to interpret that.

    - The ascii string "hello"
    - 5 single-byte integers
    - 2 two-byte integers and 0x6c as a delimiter
    - 1 four-byte integer and ending in the char "o"
    - 1 32-bit float, and one single-byte integer

etc. Or are you hoping for something that will provide you with all the possible combinations? That would produce pages of output for any decently-sized binary blob.

We found that working inside a docker container isn't usually turn-key.

You need to figure out a system to get UID/GIDs in sync between the container and the host (otherwise you mess up permissions of files in your repository. This isn't terribly hard, but is annoying boilerplate to keep writing.

Plus, docker-compose doesn't really offer command discovery. Looking at a docker compose file, I don't know how to run the project's build steps, or run their linter or tests. Having to look that up is, in my opinion, annoying.

In general, we try to provide sane defaults, so that users (and to some extent maintainers) don't need to understand Docker and how it works in order to start using it.

We did find that project as well. It's unrelated though - ours is intended to run on your local machine whereas that one seems intended to run on a server somewhere.

Unfortunate naming collision though :(