←back to thread

174 points andy99 | 1 comments | | HN request time: 0s | source
Show context
g-mork ◴[] No.43603642[source]
When did vulnerability reports get so vague? Looks like a classic serialization bug

https://github.com/apache/parquet-java/compare/apache-parque...

replies(3): >>43603809 #>>43604045 #>>43604276 #
amluto ◴[] No.43603809[source]
Better link: https://github.com/apache/parquet-java/pull/3169

If by “classic” you mean “using a language-dependent deserialization mechanism that is wildly unsafe”, I suppose. The surprising part is that Parquet is a fairly modern format with a real schema that is nominally language-independent. How on Earth did Java class names end up in the file format? Why is the parser willing to parse them at all? At most (at least by default), the parser should treat them as predefined strings that have semantics completely independent of any actual Java class.

replies(1): >>43603943 #
bri3d ◴[] No.43603943[source]
This seems to come from parquet-avro, which looks to attempt to embed Avro in Parquet files and in the course of doing so, does silly Java reflection gymnastics. I don’t think “normal” parquet is affected.
replies(2): >>43604120 #>>43604161 #
tikhonj ◴[] No.43604161{3}[source]
Last time I tried to use the official Apache Parquet Java library, parsing "normal" Parquet files depended on parquet-avro because the library used Avro's GenericRecord class to represent rows from Parquet files with arbitrary schemas. So this problem would presumably affect any kind of Parquet parsing, even if there is absolutely no Avro actually involved.

(Yes, this doesn't make sense; the official Parquet Java library had some of the worst code design I've had the misfortune to depend on.)

replies(2): >>43604367 #>>43605332 #
1. jeeeb ◴[] No.43605332{4}[source]
The Apache Arrow libraries are a good alternative for reading parquet files in Java. They provide a column oriented interface, rather than the ugly Avro stuff in the Apache Parquet library.