Re: [Last-Call] [EXTERNAL] Re: Secdir last call review of draft-ietf-jsonpath-iregexp-06

[Mike Ounsworth <Mike.Ounsworth=40entrust.com@xxxxxxxxxxxxxx>]

Hi Tim,

 

Glad I’m not completely out to lunch 😊

 

> "still not advisable to run arbitrary user-provided regular expressions on your hardware"

 

I think my point here is that regexps are code, and if you allow users to upload code and then you run it, well, then you should be prepared for the consequences 😊

 

I have never written a regexp library, so my “suggested fix” should be taken with a huge grain of salt. Maybe a paragraph like this would be enough:

 

“Note that even with the reduced scope of I-Regexp syntax, it is still possible to construct “evil regexps” that will cause parsing time and memory usage to grow exponentially with the length of worst-case maliciously-crafted input strings. Cases where applications will evaluate regexps from untrusted sources should be avoided where possible, and implementors are encouraged to check the documentation of their underlying regexp library to see if there are configurable mitigations, such as recursion depth limits, or time / memory use limits.”

 

 

If you put any sort of paragraph to that effect, then I’ll be happy.

 

---

Mike Ounsworth

 

From: Tim Bray <tbray@xxxxxxxxxxxxxx>
Sent: Monday, May 15, 2023 10:52 AM
To: Mike Ounsworth <Mike.Ounsworth@xxxxxxxxxxx>
Cc: secdir@xxxxxxxx; draft-ietf-jsonpath-iregexp.all@xxxxxxxx; jsonpath@xxxxxxxx; last-call@xxxxxxxx
Subject: [EXTERNAL] Re: Secdir last call review of draft-ietf-jsonpath-iregexp-06

 

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.

---

I was reading your note and agreeing that yes, it remains possible to devise regexps that are going to cause combinatorial nasties in almost any conceivable implementation, but unconvinced about the conclusion that it is "still not advisable to run arbitrary user-provided regular expressions on your hardware", because it seems to me that the only way to find out if the regexp is evil is to run it. 

 

But I think your closing paragraph provides a solution.

 

On Mon, May 15, 2023 at 8:17 AM Mike Ounsworth via Datatracker <noreply@xxxxxxxx> wrote:

… 

 I wonder if this
document could recommend that implementations include some sort of configurable
limit on nesting level or on recursion / backtracking depth.

 

That sounds like a good direction, but pretty complex. A simpler option would be that implementations impose a limit on time and/or memory costs and error out when those are breached. Do you think that a recommendation along those lines would address your concerns?

 

 

 

Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call