Hacker News Reader

Comment by yabones | Hacker News Reader

To me this is less about log4j, and more about giving everything root.

> The AWS account takeover was possible because a highly privileged IAM role had been assigned to the EC2 instance running the vulnerable Docker container app

The mistakes are, in order:

1. Binding an administrator IAM role to an EC2 instance, which is never ever a good thing to do, and

2. Running a docker container with full root privs - docker is not as much a security barrier as you think it is - it's only slightly better than running the application as root on the VM itself.

So yes, the log4j vulnerability is dangerous, but not nearly as dangerous as running everything as root all the time.

View on HN

Both are problems, but to me the biggest facepalm goes to log4j because anyone in their right mind should assume that log messages are untrusted input and should absolutely never have been parsed for control sequences. It's another prime example of Java over-engineering everything that should have been simple.

Don't blame the language, blame the library. At least it's not part of the standard library - in C, if you accidentally pass a user-provided string to the first argument of printf() you could be in just as much trouble.

There's a lot of over-engineering and tolerance of complexity in the Java world, more than in many other ecosystems, it's a pretty widely held view. The library is a product of the environment it evolved in.

It's not just the library. It's the entire culture surrounding Java. The language itself is fine, but Java culture is brain dead.

Isn’t log input being untrusted input an opinion?

Because in an alternative universe, they could have chosen to treat log messages like SQL where parameters are passed separately.

Obviously some people must believe that logs should be trusted input, otherwise we wouldn’t be in this situation.

That said I consider both logs and error exceptions as untrusted input, but purely on practicality.

> Because in an alternative universe, they could have chosen to treat log messages like SQL where parameters are passed separately.

They did chose to do this. The vulnerability arises even when this is done correctly.

Pseudocode:

    log("example: %s", userInput)

This is still vulnerable. The parsing that exposes the vulnerability occurs on both the format string and userInput here.

> It's another prime example of Java (...)

Log4j is not java. In fact, you can have log4c# or log4rust or log4fortran with precisely the same design, and consequently the same design problems and vulnerabilities.

Once again its no the vulnerability but how permissions are assigned to applications.

Click bait title which the author gingerly clarifies in the article to be result of poor security practices. It is obvious isn’t it?

That too, or he asumes everyone runs ec2 instances with Admin role as when people used to run LAMP as root…

> as when people used to run LAMP as root…

When was that, exactly?

I just grabbed by copy of CGI Programming on the World Wide Web by Gundavaram from 1996, and on page 368 it says:

> Most servers are set up to run with the user identification (UID) of "nobody," which means that your scripts have to be world executable. The reason for this is that "nobody" has minimal privileges.

Sure, there would always have been a few idiots who ran everything as root, but my recollection, backed up by the well-respected O'Reilly & Associates here, is that running internet-facing services with restricted privileges was the majority position for at least as long as web servers have had version numbers of 1.0+.

I think this might be a newer problem than 1996 actually. I have seen an awful lot of "modern" (2010s at least) devops which runs everything as root because the developer could not be bothered to understand the unix permissions model. I would guess that focus on security is something that waxes and wanes, rather than something that monotonically becomes more important in the culture.

To be fair, if the only thing that the server runs is the application then root or the application’s normal user doesn’t really matter much.

It should because if you can exploit the root user, it is much easier to use that machine as a lunching point for a secondary attack. Further, root will let you cover your tracks much more easily than an unprivileged user.

Just because you read it in an old book doesn't mean people practice it. Any real world experience outside a Fortune 500 will inform you that.

It takes real effort to run most of the LAMP stack as root. If you don't understand Unix permissions it's not easy. Apache, mysql, (and therefore php) all run by default as a low-privileged user. I have plenty of real world experience and haven't seen apache or mysql run as root outside of embedded devices, and even that was maybe a handful of times.

Another way to say it is that if a book says to not do something, it must be because there are people out there doing the opposite...

But the book isn't saying "You should try to make sure your web server runs as nobody". It's saying "when you're deploying your CGI programs, take into account the fact that the web server you're deploying to likely runs as nobody".

If you bind ec2 and have any access in docker you likely can GET from ec2 metadata endpoint and get sts creds, don’t need root for that.

Reply on news.ycombinator.com