Re:Third High Severity CVE in Log4j Is Published
by spockz on Saturday December 18, 2021 @06:28PM
(#29609751)
Besides this, who actually scans the deployed binaries? Just check which version of the binary was deployed, backtrack to the source, and get the dependency tree from there. Problem solved. (Except for shaded dependencies…, but scanning for that should happen at build time anyway.)
[ Parent
| on HN ]
Re:Third High Severity CVE in Log4j Is Published
by lazide on Sunday December 19, 2021 @01:06AM
(#29611810)
Good luck doing that on the custom software some vendor provided you 5 years ago and since has gone out of business.. and that’s a GOOD scenario for a lot of enterprise software. Sometimes it’s 20 years.
Re:Third High Severity CVE in Log4j Is Published
by spockz on Sunday December 19, 2021 @12:10PM
(#29615773)
Okay. Just like any other software that should be firewalled in to only connect to what it should connect to. Moreover, I think meta sploit already has this vulnerability built in so it should be trivial to test/fuzz the application.
Re:Third High Severity CVE in Log4j Is Published
by hamilyon2 on Sunday December 19, 2021 @08:35AM
(#29613800)
We need some sort of escrow for source code of closed-source product. Whenever there is practical need to have access to source code, it should be available.
Re:Third High Severity CVE in Log4j Is Published
by Too on Sunday December 19, 2021 @01:38AM
(#29611954)
Lesson learned. Never buy closed source.
Imagine the vulnerability would have been in the vendor code instead of in the log4j jar. You’d. still need a way to fix and rebuild it.
Note that this doesn’t have to mean a public MIT repo on GitHub. You can have more restrictive gray box licenses between your b2b partners only.