Sam Ruby wrote on Mon, 17 Jan 2022 01:20 +00:00: > With that out of the way, the question they really want answered is as > follows: what is different about log4j that makes it harder to update than > say Microsoft Outlook,
log4j is a component, like a screw or a battery. It's not an end-user- facing product; it is part of many different end-user-facing products. Also, Outlook [is coupled to its OS and the OS] phones home for updates, whereas log4j may or may not phone home to whoever distributed it to the end user (ASF / distro / product vendor). > what other software shares this same characteristic, and how can > manage what is deployed so that fixes get applied. Make it so people who install software in mission-critical applications are responsible for keeping that software up to date After all, that's how it works for everything else. Think of the lightbulb in an operating room: the principal responsible for maintaining it is the one who installed it, not the one who manufactured it. Criticality is not an inherent property of the software; it's a property of the software's deployment. > If there is a design defect in PCR valves affecting Toyota Corollas > manufactured in 2013, we can identify the owners of all such cars and send > them mail. Why can't we do the same for log4j? Because log4j isn't analogous to Corollas. log4j is analogous to valves. If I just order a valve off Amazon to use as a doorstop, it's not safety critical, and no regulation is needed. If the Toyota company orders a thousand valves and intends to install them in cars (3000-pound 60-mph boxes that I'm allowed to operate "because I took a 20-minute test in high school"), _then_ those valves become safety critical, and Toyota is required to be able to map valve serial numbers to VINs (which can then be mapped to vehicle owners). The valves manufacturer can't map valve serial numbers to VINs. Only Toyota can. As to introducing something similar for software, e.g., require manufacturers of self-driving cars to know exactly which "blue screen" bugs affect which cars by VIN… let's just say there's a LOT of ways to do this wrong. > And by the way, don't tell > me it can't be done as it is a national security issue, and my boss can > write Executive Orders or Legislation (depending on who is asking this > question). > > The person asking this question is more likely to be interested in SBOMs > than JNDI. > > Hopefully this helps identify the problem that needs to be solved here. > The person asking these questions is very intelligent, just focused on > different things than we are. They quickly picked up on the fact that what > was different is that log4j is open source. And they aren't pleased to > find out that that means that important things like knowing who uses that > software are very much out of our control. log4j being open source is a red herring: closed-source software with non-per-seat pricing would have the same problem. E.g., id Software can't track all shareware copies of Doom, and for that matter, central banks don't track the whereabouts of banknotes. In fact, when an old banknote design is phased out and replaced, people don't necessarily find all old-design banknotes they have in their attics or under their floors. That's a similar question to "find all unupgraded copies of log4j". > I would love to move everything currently on that page to be background > material or delete it entirely and start over if we can find a way to > address the questions I describe above. Heck the background material could > even go into how JNDI extends LDAP to cover Java Objects, and log4j allowed > (past tense) the data to be logged to point their queries at an attacker's > server who could respond not with the answer to the question posed but with > instructions on how to load their Java Object, and why that is a very bad > thing, and how you had to know about things like CORBA and RMI that were > popular 25 years ago to even figure this out. The log4j bug was ultimately down to string-typed data that contained both literal payloads and directives (like percent signs in printf(3), date(1), and crontab(5); e.g., «printf(argv[1])» is a common mistake, and compilers warn about it nowadays). Some of those directives could be used to execute code. Simplified: A string value was assigned [actually, passed as actual parameter] to string variable without being escaped/sanitized first. Simplified: There was a variable [= register, memory location] that held something's price in cents. Somebody stored in that variable the price in dollars without multiplying by 100 first (which, incidentally, is almost exactly <https://en.wikipedia.org/wiki/Mars_Climate_Orbiter#Cause_of_failure>). At which point, it's just a question of type safety. E.g., in C, using «struct in_dollars { int value; };» and «struct in_cents { int value; };» would address this. The idea would work for string types too. Net result: choosing a particular value for the ones and tens digits of the number of dollars could cause code determined by those two digits to be executed. And those two digits happened to be attacker-controlled. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
