[BUGZILLA #17766] Security vulnerabilities in bundled TRE library

[MichaelChirico]

R bundles a copy of the TRE regex library in src/extra/tre. There are a number of security issues reported against the upstream library,

• Upstream Project Zero security fixes from OS X laurikari/tre#37 (misc)
• CVE-2016-8859 (attacker controlled integer overflow in tre_tnfa_run_parallel()) laurikari/tre#45 (integer overflow)
• Infinite loop for certain regular expressions laurikari/tre#50 (denial of service)
• Null-pointer dereference in agrep for expression "{+}{7}" laurikari/tre#52 (null dereference)
• Infinite loop when matching patterns with back-references laurikari/tre#53 (denial of service)
• Integer overflow and missing checks when parsing bounds laurikari/tre#55 (integer overflow)
• Segmentation faults 2017-05-15 laurikari/tre#58 (segfault)

that likely also affect R.

Since the upstream author has ignored these issues for so long, some realism is in order: R can no longer rely on upstream to maintain this important dependency. I think it's time to either fork the library properly and fix all of these issues, or adopt another regex library (preferably one where --with-system- works).

The path of least resistance in the second direction is probably musl's regex library,

http://git.musl-libc.org/cgit/musl/log/src/regex

that is itself based on TRE. But as the git log shows, musl's copy of it is actively maintained.

---

METADATA

• Bug author - Michael Orlitzky
• Creation time - 2020-04-20 15:23:56 UTC
• Bugzilla link
• Status - UNCONFIRMED
• Alias - None
• Component - Misc
• Version - R 3.6.xx
• Hardware - Other All
• Importance - P5 normal
• Assignee - R-core
• URL -
• Modification time - 2020-04-21 19:49 UTC

[MichaelChirico]

Can you describe the attack vector for this? i.e. what would an attacker have to do to successfully compromise an R user? That might help folks make a decision as to the need to remove or alternatively update this package.

---

METADATA

• Comment author - Bob Rudis
• Timestamp - 2020-04-20 23:59:58 UTC

[MichaelChirico]

(In reply to Bob Rudis from comment #1)

Can you describe the attack vector for this? i.e. what would an attacker
have to do to successfully compromise an R user? That might help folks make
a decision as to the need to remove or alternatively update this package.

I'm not actually an R user (I work on packaging in Gentoo linux and SageMath), so anything I try to make up here will probably sound ridiculous. Maybe I can answer the question with a question: what do people use TRE regular expressions for in R? If any of those uses involve untrusted data (like parsing files from the internet), then someone could probably feed you data that triggers one of these bugs. Not the end of the world, but not nice to have in the back of your mind if you're running "grep" on a CSV file, either.

---

METADATA

• Comment author - Michael Orlitzky
• Timestamp - 2020-04-21 00:18:22 UTC

[MichaelChirico]

(In reply to Michael Orlitzky from comment #2)

(In reply to Bob Rudis from comment #1)
> Can you describe the attack vector for this? i.e. what would an attacker
> have to do to successfully compromise an R user? That might help folks make
> a decision as to the need to remove or alternatively update this package.

I'm not actually an R user (I work on packaging in Gentoo linux and
SageMath), so anything I try to make up here will probably sound ridiculous.
Maybe I can answer the question with a question: what do people use TRE
regular expressions for in R? If any of those uses involve untrusted data
(like parsing files from the internet), then someone could probably feed you
data that triggers one of these bugs. Not the end of the world, but not nice
to have in the back of your mind if you're running "grep" on a CSV file,
either.

(I asked the q primarily to set some minimum standard for future security reports, and am very [very] thankful for your thoughtful response — which was perfect!)

Let me see if this is still an issue in the 4.0.0 source tree and I'll ping R Core if so.

---

METADATA

• Comment author - Bob Rudis
• Timestamp - 2020-04-21 19:49:06 UTC