Log4j: The pain just keeps going • Hacker News Board

Re: Log4j: The pain just keeps going

#211

Post by kelnos » Wed, Jul 20, 2022, 8:26 PM UTC

leeoniya wrote: post #109

ClumsyPilot wrote: post #107

Earlier quoted context omitted.

because our industry is obsessed with abstractions - the moto is to never fix anything, just pave over it with another abstraction. for example we didnt fix how we build applocations and manage dependancies, we invented docker. we didn't create a secure runtime for the cloud where applications can run, instead we virtualised whole operating systems

> because our industry is obsessed with abstractions "we do not break userland, period" -- Linus Torvalds not breaking existing stuff is why many abstractions exist, and even why many are put in place early on, to allow for some wiggle room without having to break all the things. people tend to prefer software that continues to work, above all else.

I think we should acknowledge, though, that not all abstractions are created equal. Abstractions that hide implementation details and allow people to change those implementation details without creating churn and extra work for their downstream consumers are good.

Abstractions that paper over problems that you are unwilling or undisciplined enough to tackle properly are usually bad. I think the grandparent was talking about this kind.

Re: Log4j: The pain just keeps going

#212

Post by YetAnotherNick » Wed, Jul 20, 2022, 8:27 PM UTC

layer8 wrote: post #165

hyperman1 wrote: post #27

I never understood where log4j 2 was supposed to fit in the ecosystem. * We had log4j 1, which was good enough for most use cases and everywhere. * We had slf4j/logback, which was from the same authors, and broke backward compatibility but gave us a fundamentally better design. * We had java.util.logging, which while braindead was builtin to Java and hence available everywhere. *We had commons logging, which was neve…

> Then apache decides to put new people on log4j, do a backward incompatible v2 design that nevertheless is worse than slf4j. Why? Because the original Log4j author wanted to do his own thing for a Log4j successor (slf4j/logback), and the Apache Log4j maintainers also had ideas about a next-gen framework and wanted to do that. That’s Open Source, everyone can do their own thing if they like, and some things will get…

Hearing logging library and next-gen framework in the same sentence would never not make me laugh.

Re: Log4j: The pain just keeps going

#213

Post by kelnos » Wed, Jul 20, 2022, 8:31 PM UTC

TheCapn wrote: post #175

fisf wrote: post #92

Earlier quoted context omitted.

Software engineers are mostly aware of this. There is just little market demand for this level of robustness.

Engineering Code of Ethics dictate that safety of public and environment is paramount. I know that's true for my P.Eng governing body; it is written into our bylaws. I'm sure its the same for most others as well. I think until Software Engineering catches up in this regard with traditional Engineering disciplines we'll continue to see issues arise from the software realm. As much as the self-titled "Engineers" procla…

I've always been uncomfortable calling myself a "software engineer" for this reason, and usually refer to myself as a "software developer". Most of the job listings I see at various companies use "engineer" though, and so my official title ends up being "engineer", so that's what I end up putting on my resume. (Though I guess I don't really need to do that; I could put whatever I want.)

Re: Log4j: The pain just keeps going

#214

Post by ylk » Wed, Jul 20, 2022, 8:33 PM UTC

kriro wrote: post #97

horsawlarway wrote: post #78

Earlier quoted context omitted.

I was in this industry for a while (I did 5 years full time for a security company). > I will concede there probably are some firms out there acting poorly that way. This is a hilarious take. Here's mine: The vast majority of these firms are here for liability. They do not provide security, they provide security theater so that if/when something goes wrong, the client can claim to have followed best practices, and th…

Thank you, that is a very interesting take. I've always played with the idea of pivoting into the security industry because playing hack the box and the like is something I do in my free time and enjoy. Maybe I'll just do some bug bounties or something for fun instead. I think it's a bit different in Europe though at least anecdotally there seems to be more code audit and the like (more product security) instead of p…

I'd say don't let yourself be discouraged by GP. Just look into a company before you apply. Many have public reports and/or security research, both of which you could use as indicators.

Here's a repo with lots of public reports by various consultancies, you could use that as a starting point: https://github.com/juliocesarfort/public-pentesting-reports

Re: Log4j: The pain just keeps going

#215

Post by kelnos » Wed, Jul 20, 2022, 8:38 PM UTC

laughingbovine wrote: post #148

shepherdjerred wrote: post #128

Earlier quoted context omitted.

> So the exact software you compile will depend on whether or not you can connect to a 3d party service? Do you understand the actual implications of this? This is already true with the vast majority of software using any an online software repository, e.g. Go, NodeJS, Java, Rust, etc.

Yeah but you can cache the packages or store them in some fashion. I've seen JAR files in git repos far too many times... With security, you need some online service so you can find the new CVEs every day.

> With security, you need some online service so you can find the new CVEs every day.

Or you just do it manually if that service is down. It's weird to me that the argument for not having an automated, 3rd-party service is "if it goes down then you'll have to do things manually", when the alternative is "you always have to do it manually".

If you are comfortable trusting a third-party service to tell you when to upgrade, then that is absolutely an improvement over doing security updates manually. This is why I have unattended-upgrades set up on my Debian systems to automatically install updates from Debian Security every day. Sure, it may fail for whatever reason, but I am certainly not going to take the time to (or even remember to) update every day.

Re: Log4j: The pain just keeps going

#216

Post by twic » Wed, Jul 20, 2022, 8:40 PM UTC

layer8 wrote: post #165

hyperman1 wrote: post #27

I never understood where log4j 2 was supposed to fit in the ecosystem. * We had log4j 1, which was good enough for most use cases and everywhere. * We had slf4j/logback, which was from the same authors, and broke backward compatibility but gave us a fundamentally better design. * We had java.util.logging, which while braindead was builtin to Java and hence available everywhere. *We had commons logging, which was neve…

> Then apache decides to put new people on log4j, do a backward incompatible v2 design that nevertheless is worse than slf4j. Why? Because the original Log4j author wanted to do his own thing for a Log4j successor (slf4j/logback), and the Apache Log4j maintainers also had ideas about a next-gen framework and wanted to do that. That’s Open Source, everyone can do their own thing if they like, and some things will get…

I use java.util.logging in a few apps, to cut down on dependencies, and i consider it to be fairly braindead. The fundamentals are okay, to the extent that they are copies of log4j, but there are a bunch of little things that just aren't done right, like:

- logging methods taking arrays rather than varargs (this would be a trivial change!)

- there being no way to create a SimpleFormatter with a custom format in code other than setting a system property before creating it

- there being no Logger:getLogger override which takes a class, only strings

At some point, i am going to write a little facade which wraps jul and fixes the papercuts, which feels like a very silly thing to be doing!

Re: Log4j: The pain just keeps going

#217

Post by alcover » Wed, Jul 20, 2022, 8:41 PM UTC

stonemetal12 wrote: post #168

gnulinux wrote: post #151

Earlier quoted context omitted.

Quite the opposite, we have very safe languages now in 2022. Any software that's not written in Rust or Haskell has to explain the trade-off of being written in an unsafe language. Of course the industry will still use unsafe languages, but we lack the awareness that we're intentionally writing garbage software in garbage languages that should be treated as radioactive material in any context where safety matters. If…

These Log4j issues aren't real hardcore exploits. They wrote a logger that could run arbitrary code, then were surprised when attackers figured out how to run arbitrary code. It isn't a language problem, it is a developer practices problem. Developers code like security isn't a thing then are confused when their programs aren't secure.

  It isn't a language problem

Exactly. This flamy sub-thread has no point here.

Re: Log4j: The pain just keeps going

#218

Post by cmckn » Wed, Jul 20, 2022, 8:42 PM UTC

jacobyoder wrote: post #12

Had to deal with some automated scan tool telling a client "you have log4j - you're vulnerable!" when... we didn't. A project was including a dependency on SLF4J and that project pulled in slf4j-log4j (IIRC). But it was not configured, wasn't compiled in to the final jar, and ... even it was, it was very old log4j (1.1 or 1.2 IIRC?). The vulnerability didn't affect that older version. We had to spend a week back and…

> we can't reasonably fork the entire dependency just to remove that one sub-dependency from our project's dependency

If you use Maven, just exclude that transitive dependency from the explicit dependency.

But yeah, dumb warnings are dumb.

  
    com.example
    my-dependency
    
      
        org.slf4j
        slf4j-log4j12

Re: Log4j: The pain just keeps going

#219

Post by bostik » Wed, Jul 20, 2022, 8:44 PM UTC

jacobyoder wrote: post #12

Had to deal with some automated scan tool telling a client "you have log4j - you're vulnerable!" when... we didn't. A project was including a dependency on SLF4J and that project pulled in slf4j-log4j (IIRC). But it was not configured, wasn't compiled in to the final jar, and ... even it was, it was very old log4j (1.1 or 1.2 IIRC?). The vulnerability didn't affect that older version. We had to spend a week back and…

We (read: I) face this on an ongoing basis.

We can't upgrade the entire components that bundled up log4j for various reasons, starting from licensing rules. So we made the decision to strip out the entire JndiLookup class from every project that uses java. Clients do various scans, and rely on dumb version string matching and/or banner grabbing. We have to routinely point them to our VERY detailed and explicit log4j response document, and carefully explain to them that their scanners are relying on insufficient detection methods.

Security teams are quite content with us giving them detailed explanation about the false positive. And then they forget or deliberately choose to ignore the lesson and the next time they run their scans, get the same false positives again.

Even supposedly state-of-the-art security tools, to this day, refuse to actually verify their detections.

Re: Log4j: The pain just keeps going

#220

Post by treeman79 » Wed, Jul 20, 2022, 8:46 PM UTC

btilly wrote: post #173

aclatuts wrote: post #160

Earlier quoted context omitted.

I find Python is very prone to a lot of breaking changes even with minor version changes. And not just that, even minor versions have to match up specifically with another libraries minor version. It seems to be a community or ecosystem problem with Python, which is why I avoid Python as much as possible. In every other ecosystem when minor version are updated there are very rarely issues, and there are little issues…

My (somewhat dated) experience says that Ruby is all the way worse than Python on this. In part due to a culture that encouraged monkeypatching. With the result that what behavior you get depends on who last monkeypatched it. So a dependency 3 deep that loads the module you expected to load last suddenly causes the monkeypatch you were depending on to disappear...

Monkey patching was the greatest thing ever. Until the community realized how bad it was. Don’t see it much these days