6 ms·

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 as

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.

kristianpaul 5y ago
Once again its no the vulnerability but how permissions are assigned to applications.
la6471 5y ago
Click bait title which the author gingerly clarifies in the article to be result of poor security practices. It is obvious isn’t it?
- kristianpaul 5y ago
  That too, or he asumes everyone runs ec2 instances with Admin role as when people used to run LAMP as root…
  - Karellen 5y ago
    > 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+.
    - tlackemann 5y ago
      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.
      - ufo 5y ago
        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...
        Karellen 5y ago
        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".
      - bink 5y ago
        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.
    - aftbit 5y ago
      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.
      - Nextgrid 5y ago
        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.
nrdvana 5y ago
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.
- adambatkin 5y ago
  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.
  - TheCoelacanth 5y ago
    It's not just the library. It's the entire culture surrounding Java. The language itself is fine, but Java culture is brain dead.
  - fulafel 5y ago
    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.
- thrashh 5y ago
  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.
  - zenexer 5y ago
    > 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.
nhoughto 5y ago
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.

kristianpaul 5y ago

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

la6471 5y ago

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

kristianpaul 5y ago
That too, or he asumes everyone runs ec2 instances with Admin role as when people used to run LAMP as root…
- Karellen 5y ago
  > 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+.
  - tlackemann 5y ago
    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.
    - ufo 5y ago
      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...
      - Karellen 5y ago
        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".
    - bink 5y ago
      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.
  - aftbit 5y ago
    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.
    - Nextgrid 5y ago
      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.

nrdvana 5y ago

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.

adambatkin 5y ago
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.
- TheCoelacanth 5y ago
  It's not just the library. It's the entire culture surrounding Java. The language itself is fine, but Java culture is brain dead.
- fulafel 5y ago
  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.
thrashh 5y ago
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.
- zenexer 5y ago
  > 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.

nhoughto 5y ago

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.