On Sun, Jan 16, 2022 at 6:59 PM Gilles Sadowski <[email protected]> wrote:
> Le dim. 16 janv. 2022 à 22:27, Sam Ruby <[email protected]> a écrit : > > > > On Sun, Jan 16, 2022 at 1:49 PM Dominik Psenner <[email protected]> > wrote: > > > > > I have no intention to tear apart the document. I am dealing with non > > > technical fellows on a daily basis and from my experience the document > > > still too technical. > > > > > > > That's what I was afraid of, and what I very much want to fix. > > From [1]: > ---CUT--- > Log4j is a chunk of laptop code that builders can put into purposes > to watch, or “log”, something from mundane operations to vital alerts. > Those detailed logs may also help programmers debug software and > is used by tens of millions of purposes. > ---CUT--- > > How much less technical can it be? > > No. They've read that. It doesn't answer their questions. They have come to us to get the answers. Analogy: my car is broken. I take it in to be fixed. The mechanic starts to explain how the car works. I stop him and ask him how much the car will cost to be fixed and when it will be ready. The mechanic responds by explaining how the car works in simpler terms. Feel free to update the page, but my opinion is that the description you cited doesn't answer any question the user may be wanting to ask. See below. > >> [...] > > > > I actually don't think we go there. Essentially there is a recall on a > > thingamabob. Most people don't know how cars work either, but when they > > get a recall, they take it in to get fixed. > > The people who don't know how cars work are not the people who > get to decide when a safety recall is warranted. > I'm confused about what can be undertaken by an audience that > does not understand what "code" means in this context. > > > What's different here is that > > it is not just one model or even make of a car that is getting recalled, > > but rather a large number of different manufacturers that are affected. > > And they are wondering why this is, > > As noted in the quote above: The component provides a functionality > that can be plugged in any software. > > > and want to make sure that it doesn't > > happen again. > > In Log4j, or in any open source software, or in any software? > > > > [...] > > > > Unfortunately, I don't know of a good analogy for open source. > > Doesn't the focus on "open source" entertain an a priori that it > increases the risk of vulnerabilities (while it can be construed that > it rather increases the likelihood that vulnerabilities are discovered > before they can be exploited)? > No. In a nutshell: My laptops and phones need to be updated regularly. There is a well defined process for doing so. The process is manageable. At times, annoying, but mostly painless. Open source vulnerabilities are indeed rarer, but the impact in this case is both wider and unknown. And very painful. Something important is different. Something that transcends this specific issue. The fact that this time it was log4j this time is beside the point. When I've seen this explained, the fact that the problem wasn't known at the time it was introduced, and involved multiple components from different vendors was enough to satisfy the person asking the question. Anything more and eyes glaze over. 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, what other software shares this same characteristic, and how can manage what is deployed so that fixes get applied. 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? 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. 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. Regards, > Gilles > > [1] > https://mywinet.com/some-federal-systems-affected-by-software-flaw-us-official-says/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: > [email protected] > - Sam Ruby
