[
https://issues.apache.org/jira/browse/ORC-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Arce updated ORC-2214:
----------------------------
Priority: Minor (was: Critical)
> Harden RLE integer decoders against buffer cursor overshoot
> -----------------------------------------------------------
>
> Key: ORC-2214
> URL: https://issues.apache.org/jira/browse/ORC-2214
> Project: ORC
> Issue Type: Improvement
> Components: C++, RLE
> Reporter: Roman Arce
> Priority: Minor
>
> A malformed/truncated RLE stream can drive the C++ RLE integer decoders' read
> cursor past the end of the internal stream buffer, causing out-of-bounds heap
> reads (detected by AddressSanitizer as heap-buffer-overflow READ) when
> reading a crafted ORC file via the public reader API.
> Root cause: RleDecoderV2::bufLength() (c++/src/RLEv2.hh) returns the raw
> (unsigned) pointer difference between bufferEnd_ and bufferStart_; once the
> cursor overshoots (bufferStart_ > bufferEnd_) this underflows to a value near
> 2^64, defeating the std::min clamps in the UnpackDefault bit-unpacking fast
> loops (BpackingDefault.cc). Separately, RleDecoderV2::readByte() and
> RleDecoderV1::readByte() gated their buffer refill on strict equality
> (bufferStart_ == bufferEnd_), so an already-overshot cursor skips the refill
> and dereferences out of bounds.
> Impact is limited to a crash / out-of-bounds read while parsing an untrusted
> file (no write, no code execution demonstrated). This was reported privately
> to [email protected]; per the project's published security model
> (https://orc.apache.org/security/), a crash on malformed input is out of
> scope as a vulnerability, and ASF Security (Arnout Engelen) invited
> submitting the fix as a hardening improvement through the normal contribution
> channel.
> A PR implementing the fix is already open: apache/orc#2691 — "Harden RLE
> integer decoders against buffer cursor overshoot"
> (https://github.com/apache/orc/pull/2691). It has been validated against the
> full C++ unit suite (752/752 passing) and against AddressSanitizer-built
> reproduction cases (31/31 previously-crashing malformed-file cases now
> handled cleanly).
> This issue was created at the request of @luffy-zh in the PR discussion,
> since the project tracks changes in JIRA rather than GitHub Issues.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
