421–430 of 531 posts
Is there any reason to believe this wouldn't affect log4net in the same way?
12 years of experience with .Net here - it’s been a long time since I used log4net and I was never intimately familiar with it, but I’m not aware of any built-in or common .Net functionality that will make a web request and remotely load code just by parsing a string. So unless the log4net library totally implemented that feature from scratch, it should be safe.
Well obviously we need a way in our LOGGING LIBRARY to download binary blobs off the Internet and execute them from log messages. Sigh
This is what has me scratching my head. What is the usecase that somebody is using LDAP to load remote classes? I am your run of the mill CRUD developer but I haven't had to load remote classes ever. Is this some framework level stuff? Was this an opt-in kinda scenario?
"Here's a feature I just thought of"
"Boom. Merged."
That kind of interaction isn't uncommon. Lots of projects in this ecosystem are abstractions built on abstractions, and value features over everything else.
To folks wondering what the issue is about, I'll give a short summary that I myself needed. Typically a logging library has one job to do: swallow the string as if it's some black box and spit it elsewhere as per provided configurations. Log4j though, doesn't treat strings as black boxes. It inspects its contents and checks if it contains any "variables" that need to be resolved before spitting out. Now there's a bun…
Does this affect SL4j wrappers over log4j as well ?
From https://web.archive.org/web/20040908114732/http://www.sun.co...
I guess the marketing claims were true. I am completely mystified why this feature exists.
I've been thinking about this since I saw it here on HN yesterday, and I can't help but entertain the idea that this might end up being 'the worst software security flaw ever'.
nah, it's just a logging package that not everyone uses. it would be much worse if it was in an OS of some sort.
I’m amazed at the reaction here. Lots of comments ITT about how this library is horrible and logging should be a solved problem from a security perspective. Similar commentary was here recently regarding some unsafe docker default. Developers always want abstractions to make programming easier, but they never consider the cost of using those abstractions. It’s so convenient to place all the burden on library authors…
> Put a regex whitelist on your inputs wherever there’s a trust boundary. No. That's a horrible idea because it requires you to think about security in multiple places and get it right every time. Instead I am going to wrap the horrible logging library that does not automatically escape control characters within arguments in a wrapper that does. Now it's impossible for me to mess up. Or... you know. One could have de…
Earlier quoted context omitted.
I might be missing something, but wouldn't the point be that it's not the log writer's responsibility to do this, but rather some other service that consumes the unparsed output and sends the notification?
This is the obvious solution now. I think 20 years ago it would have been slammed as overkill to have a separate process just to send logs. Even now actually, there is a flurry of libs/gems to send events/logs/analytics to a remote server (Datadog, NewRelic, Slack…)from the application itself. It’s usually not directly coupled with the logger, but it’s not far.