Unless you're logging user input without proper validation, log4j doesn't really seem that bad.
As a library, this is a huge problem. If you're a user of the library, you'll have to decide if your usage of it is problematic or not.
Either way, the safe solution is to just update the library. Or, based on the link shared elsewhere (https://github.com/apache/parquet-java/compare/apache-parque...) maybe avoid this library if you can, because the Java-specific code paths seem sketchy as hell to me.
It’s incredibly common to log things which contain text elements which come from a user request. I’ve worked on systems that do that 100s of thousands of times per day. I’ve literally never deserialized a parquet file that came from someone else even a single time and I’ve used parquet since it very first was released.
> Unless you're logging user input without proper validation, log4j doesn't really seem that bad.
Most systems do log user input though, and "proper validation" is an infamously squishy phrase that mostly acts as an excuse. The bottom line is that the natural/correct/idiomatic use of Log4j exposed the library directly to user-generated data. The similar use of Apache parquet (an obscure tool many of us are learning about for the first time) does not. That doesn't make it secure, but it makes the impact inarguably lower.
I mean, come on: the Log4j exploit was a global zero-day!
> Most systems do log user input though, and "proper validation" is an infamously squishy phrase that mostly acts as an excuse
That's my point: if you start adding constraints to a vulnerability to reduce its scope, high CVE scores don't exist.
Any vulnerability that can be characterised as "pass contents through parser, full RCE" is a 10/10 vulnerability for me. I'd rather find out my application isn't vulnerable after my vulnerability scanner reports a critical issue than let it lurk with all the other 3/10 vulnerabilities about potential NULL pointers or complexity attacks in specific method calls.
> Any vulnerability that can be characterised as "pass contents through parser, full RCE" is a 10/10 vulnerability for me
And I think that's just wildly wrong sorry. I view something exploited in the wild to compromise real systems as a higher impact than something that isn't, and want to see a "score" value that reflects that (IMHO, critical) distinction. Agree to disagree, as it were.
The score is meant for consumption by users of the software with the vulnerability. In the kind of systems where Parquet is used, blindly reading files in a context with more privileges than the user who wrote them is very common. (Think less "service accepting a parquet file from an API", more "ETL process that can read the whole company's data scanning files from a dump directory anyone can write to".)
I get the point you’re making but I’m gonna push back a little on this (as someone who has written a fair few ETL processes in their time). When are you ever ETLing a parquet file? You are always ETLing some raw format (css, json, raw text, structured text, etc) and writing into parquet files, never reading parquet files themselves. It seems a pretty bad practise to write your etl to just pick up whatever file in whatever format from a slop bucket you don’t control. I would always pull files in specific formats from such a common staging area and everything else would go into a random “unstructured data” dump where you just make a copy of it and record the metadata. I mean it’s a bad bug and I’m happy they’re fixing it, but it feels like you have to go out of your way to encounter it in practice.
This comment over generalises the problem, but is inherently absurd. There are key indicators in scoring that explain the attack itself which isn't environment specific.
I do agree that in most cases the deployment specific configuration affects the ability to be exploited and users or developers should analyse their own configuration.
Funny how this popped up as I was just talking to a friend about some of the challenges I've had with logging. Would definitely be interested in contributing to a project like this. Hit me up (email in profile).
Are you saying you think the Canadian government should pay more toward fertility and less toward LGBTQ procedures such as gender reassignment? I wonder how much money the latter costs. Seems like it wouldn't be as big a cost vs fertility treatments being covered.
What switches enterprise or consumer tend to support this LLDP? My guess is maybe almost none on the consumer side. I.e. Netgear, to link. Cisco probably does. How about ubiquti?
Anything with a management interface (even web) could do it from the HW side, just a question of SW support. Netgear does support it on managed switches.
The protocol is old enough and very well established by now, even modern Windows boxes run it by default.
I know mikrotik supports this. On the higher end, most of the Dells switches I interacted with as well as Aruba had LLDP. Different manufacturers tend to report their interfaces slightly differently though
Nope, you need switch silicon with a driver that punts 01:80:c2:0:0:0e to cpu. A lot can do this but not all (generally a driver issue, not HW limitation.)
Long term this is good for the software ecosystem as a whole. Especially open source options like proxmox. I think Broadcom is making a strategic business mistake not willing to negotiate in good faith. However this is the true cost of using closed source solutions. The more this happens the more it gets factored into business decisions.
