Jun 4, 2022Liked by CannCon

Dang Brian!!! Awesome work. You know this stuff better than anyone else I follow and you do an excellent job of presenting it!!

Expand full comment

This was great to look over, thanks for putting all this together!

Regarding the"Greek" - something that you may find helpful. I think understanding these concepts gives a little more dimension to just how vulnerable these systems are in ways you haven't commented on above. Even though these analogies are probably nails on a chalkboard to a real cyber security expert, here's my stab at it.


"does not validate application signatures to a trusted root certificate"

Let's say you bought a ticket at a concert. You show up, show your ticket, and the gatekeeper lets you in.

The guy just behind you says "hey, sorry, I don't have a ticket, but here's a piece of paper where I wrote down the time and amount I paid, and my seat." The gatekeeper lets him in, too.

Then the next guy passing down the street overhears that, changes course, pulls a piece of paper out of his pocket, writes some stuff down, and uses the same excuse to get into the concert. The gatekeeper just lets him through.

At this point, you may wonder why you bothered to print out the ticket in the first place when you could just write up your own on a crumpled up piece of paper.

Each attendee is a process (software) that needs to make sure it gets approval to do what it's doing by the root (gatekeeper). Not every single action it does after getting in can be monitored, so the system assumes it should be OK as long as it has a valid cryptographic key (the ticket.) When this ticket isn't checked against a verifiable standard .... well ...


Your car isn't starting, so you take it to the shop. They first check the blinker fluid, then the tire pressure, then the gas tank. They give you a report, charge you a bunch of money, and give you your keys back. Would you trust that they know how an engine *should* start up? How would you measure their competence? What if they just assured you they knew what they were doing, and you didn't know what you were talking about?

Both the "should" and the "measurement" are accomplished by creating a one-way hash as the computer system starts up. The central processor does this by going through a checklist at startup, computing the hash value, and storing it permanently (cannot be rewritten.) This issue means one, two, or all three of those steps are not happening.


"ImageCast X has a Terminal Emulator application"

Oh boy, this is a good one. Since we're talking about cars, let's stick with that one. Let's say you got a Tesla. You want to open up the hood on that thing up and start soldering connections? Probably not, you just want to drive it and let the experts get under the hood. You know you could do more damage than good if you go under the hood.

In fact, Tesla probably won't even let you get under the hood because they know you'll screw it up. So you can't get access to certain parts of the car without very specific tools that are only accessible by their approved technicians.

You know what that terminal application is they talk about? Yeah, it's a multi-function tool that let's anybody get under the hood.


"ImageCast X allows for rebooting into Android Safe Mode, which allows an attacker to directly access the operating system"

When you wake up one morning and your back is out, you go to the doctor to figure out how to re-align it. That means you get laid out in a vulnerable position while he works on you (chiropractor), images you (x-ray), or drugs you (surgery). One way or the other, that is not your normal state - you're only in that state to be directly influenced under the practitioner's control, assuming he knows what's best.

Safe Mode is a mode on a computer that allows an administrator (hence reference to "escalated privileges") to debug something that went wrong. Maybe the memory needs a check run, maybe registers need to be edited, maybe standard security needs to be disabled to find the problem. In any case, if that mode is exposed to an attacker, it is all too easy to put a twist in the computer's normal function.


"cause arbitrary code execution by specially crafted election definition files"

Let's say you're asking me for travel advice in Germany, and I tell you the very best thing to do is to coddiwomple Bavaria- everything else is a side-show. You don't happen to know what "coddiwomple" means, and I never explained myself, so you go look it up on Wikipedia.

Unbeknownst to you, the definition of that word in Wikipedia just changed between when I used the word, and when you looked it up. Instead of what I meant - to go with certainty in an uncertain direction - now Wikipedia says otherwise - to throw oneself off a cliff.

Having the ability to change definitions on the fly like that is a problem. Suddenly what the system thinks it should be pointing to changes fundamentally - so there's no consistent way to evaluate what went wrong unless you captured the definition in that particular moment.


Let's go back to an auto example. Let's say you took your Tesla in to get worked on, expecting a mechanic to work on it. After you give the keys away, you happen to look through the window and notice the mechanic left your car for a moment.

A random guy off the street walks up to your car, looks inside, grabs some spare clothing and tools that make him look like a mechanic, and starts digging around under the hood of your Tesla. The real mechanic comes out, sees someone else is working on your car, and walks away, thinking someone else is handling it.

You turn around and ask "hey, does that guy work for you? Is he a mechanic?" The guy in the office looks up, sees a guy in mechanic's clothes, and says "well, I don't know him personally, but he probably works for us."

Does that seem like a normal situation? No, because you watched it happen, and everyone else just assumed he had the right privileges because he was wearing the clothes.

That's what this means about the ability to allow a random software to a "system level service." System level should be maintenance only, and will be allowed to do more things "under the hood" than a regular application should be able to do.

Lastly, I think the last three are pretty self-explanatory.




Expand full comment