Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Log4Shell update: second Log4j vulnerability published

lunasec.io

Post reply on HN
Print view View original

281–289 of 289 posts

Re: Log4Shell update: second Log4j vulnerability published

#281

Post by john-shaffer »

Hallucinaut wrote: post #269
sporkland wrote: post #229

Earlier quoted context omitted.

Yes

Whilst that is ridiculous if they're bringing in a new dependency, if I squint I can see the thought process. Transitive dependencies are far harder to be certain about. It took a few seconds to scan our company's entire code base for log4j2. But there's no easy way to verify that none of them might depend on, say, Spring Boot Web Starter, which brings in umpteen other dependencies. Sure, you can resolve dependencies…

I just added a test case that importing org.apache.logging.log4j.core.lookup.JndiLookup throws a ClassNotFoundException. Any log4j2 class would work too.

Re: Log4Shell update: second Log4j vulnerability published

#282

Post by syntheticcorp »

justin_oaks wrote: post #235
sporkland wrote: post #171

Earlier quoted context omitted.

I'm seeing instances of it making the debt worse rather than better. E.g. some folks are just forcing latest log4j libs into builds even for services that don't have it or need it in central dependencies, as it's more expedient than trying to be precise and only bump where necessary. Leading to more risk over time.

It may not make any sense, but how does it lead to more risk? If you add a Java dependency but nothing calls it, then you're not vulnerable.

If it’s in the class path? Deserialisation gadgets.

Re: Log4Shell update: second Log4j vulnerability published

#283

Post by qalmakka »

HappyDreamer wrote: post #275
qalmakka wrote: post #228

Earlier quoted context omitted.

The difference is that being pwned by a random memory corruption, while unfortunate, is an unintended feature. This on the other hand provides a deliberate, standardized and convenient way to allow anyone to download *any* arbitrary code into a running JVM. This is something that it is NEVER ok, not in any form or fashion, not even your own network unless you enable some huge debug flag, and it's WAY worse than eval(…

A bit hyperbole? Agreed that these features should be off by default, or removed -- maybe could be included only in a special JVM build, Still, in Python you can GET and eval: r = urllib.request.urlopen(url).read() d = literal_eval(r.decode()) Here's someone "Fetching and evaluating Python code from an HTTP response": https://stackoverflow.com/questions/28047761/fetching-and-ev... Edit: Apparently `literal_eval` isn'…

The situation you describe is arguably different, if you eval() code you just fetched from an HTTP server you are deliberately, knowingly doing something very dangerous and it's only your fault. You are the one loading and cocking the gun.

By the way, you can do the same thing everywhere, nothing stops you from doing

    system("sh -c \"wget -O - someurl | gcc -x c - && ./a.out\"")
in C and allow the world to pwn you. What is arguable here is that in this case it is definitely not the language or the system's fault if their users are so dumb to invent a creative way to abuse a facility intended for a different use.

Viceversa, the JRE includes and standardizes facilities to potentially download and execute code without any reasonable sandboxing by default, out of the box, in the standard install. It's as if Python had mandated by standard to check if the data passed to `eval()` is an HTTP URL in order to download and eval() whatever resides at that address. It's not the same by any margin. One thing is to shoot yourself in the foot by mistake , one other is to have in your toolbox a device that by design chops your feet off. The thing that bewilders me is that the whole "let's download untrusted .class files from the Internet" thing was a deliberate design choice and it took people 25 years to realize how idiotic it was. There's a whole sea of difference between that and what you've described.

Re: Log4Shell update: second Log4j vulnerability published

#284

Post by garblegarble »

est wrote: post #231
thomond wrote: post #176

Earlier quoted context omitted.

It really re-enforces the idea of sane defaults. How many end users of a logging framework would even need JNDI functionality?

> How many end users of a logging framework would even need JNDI functionality Serious question: Suppose you need to replace user ids with user names in your Java program logs, instead of writing LDAP lookups around every log line everywhere, you have to put it in some module no? How about wrap the logging framework?

Why on earth would you want more PII in your logs?

Re: Log4Shell update: second Log4j vulnerability published

#285

Post by yccs27 »

hutzlibu wrote: post #189
eptcyka wrote: post #188

Earlier quoted context omitted.

One has to be very trusting of you to give you an RCE to plug security holes

If you do not trust them, you probably should not use their code, without deeper examination, either.

The bigger problem is: You not only have to trust their good intentions now, but you also need to be able to trust them in the future, as long as the script is active. Additionally, you have to trust/hope that the patch security is absolutely waterproof and does not give RCE to attackers.

Re: Log4Shell update: second Log4j vulnerability published

#286

Post by corpMaverick »

hu3 wrote: post #227
corpMaverick wrote: post #187

Why is this so hard? It should be very easy to fix this. Set the correct version in the pom.xml. Commit and push to master and deploy. right? easy. It should be a half an hour thing. But at my employer, we still have dozens of teams struggling. Two reasons: - Branching hell.- Many teams don't do continuous integration. They have branches over branches over branches. There are many changes that are not in prod. Contin…

> Many teams don't do continuous integration. They have branches over branches over branches. There are many changes that are not in prod. Continuous integration is about integrating several times a day. David Farley frequently talks about this. https://www.youtube.com/watch?v=Xl62gQpAl1w Preach. As a consultant, I have been trying to implement continuous integration in a team and it has been so hard to convince proj…

Yes. I have encounter similar behaviors in several places already.

Re: Log4Shell update: second Log4j vulnerability published

#287

Post by NaturalPhallacy »

stef25 wrote: post #109
NaturalPhallacy wrote: post #61

Earlier quoted context omitted.

There's no good reason to do elections on anything other than paper.

If there's no way to build secure software that tallies digits then why are we even here?

It's not about tallying digits, it's about maintaining the secret ballot, and making it really hard to commit election fraud. (As opposed to voter fraud, which is an insignificant problem.)

It's such a bad idea that Tom Scott has not one, but two videos on it:

https://www.youtube.com/watch?v=w3_0x6oaDmI (Computerphile channel)

https://www.youtube.com/watch?v=LkH2r-sNjQs (his channel, more recent)

And also, if 20 people can handle ballots from 1000 people (no clue if that's realistic but it doesn't matter), then if you add another 1000 people.

Well... since you added people and the resource you need to count is people it's a self scaling solution. Sure you might need larger facilities, but we're not exactly running out of schools (another thing tied to the population).

The only reasons to make voting electronic are:

* To make money

* To commit election fraud

which is why I said there are no "good" reasons. :)

Re: Log4Shell update: second Log4j vulnerability published

#288

Post by anang »

HappyDreamer wrote: post #275
qalmakka wrote: post #228

Earlier quoted context omitted.

The difference is that being pwned by a random memory corruption, while unfortunate, is an unintended feature. This on the other hand provides a deliberate, standardized and convenient way to allow anyone to download *any* arbitrary code into a running JVM. This is something that it is NEVER ok, not in any form or fashion, not even your own network unless you enable some huge debug flag, and it's WAY worse than eval(…

A bit hyperbole? Agreed that these features should be off by default, or removed -- maybe could be included only in a special JVM build, Still, in Python you can GET and eval: r = urllib.request.urlopen(url).read() d = literal_eval(r.decode()) Here's someone "Fetching and evaluating Python code from an HTTP response": https://stackoverflow.com/questions/28047761/fetching-and-ev... Edit: Apparently `literal_eval` isn'…

If I understand right, the equivalent in python wouldn't be

    r = urllib.request.urlopen(url).read()
    d = literal_eval(r.decode())
But rather:

    r = urllib.request.urlopen(url).read()
    logging.info(r.content)
Wouldn't that be pretty insane if the those two code fragments were functionally equivalent?

Re: Log4Shell update: second Log4j vulnerability published

#289

Post by Quekid5 »

_flux wrote: post #142
Quekid5 wrote: post #130

Earlier quoted context omitted.

Python 3.10.1 (main, Dec 11 2021, 17:22:55) [GCC 11.1.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> print(f"""{print("hello")}""") hello None So Python runs the expression in { } and interpolates the result into the string. Presumably the { } has access to anything that's in scope. (I'm not quite sure how common patterns are, but I assume the person is replying to is imagining…

You may find that actually making this code to use data from user-provided data will make the code look quite unnatural and I doubt it would be accidentally written. For example: >>> user_data='{print("helo"}}' >>> print(user_data) {print("helo"}} >>> print(f"{user_data}") {print("helo"}} >>> print(f"user_data") user_data >>> print(user_data.format()) Traceback (most recent call last): File " ", line 1, in KeyError:…

Yeah, that's why I was quite skeptical about the exact scenario... it would probably look very out of place, but I don't have enough RW experience in Python to say for sure.
Post reply on HN