They seem to be fuzzing the regex, not just the input it is applied to. This may or may not change the results, but if you're allowing users to input arbitrary regex patterns you have a whole lot of other problems.
Regex: badly needs fuzzing
11–20 of 180 posts
Re: Regex: badly needs fuzzing
#12Another counterexample to the idea that modern C++ written by experts is free of memory safety issues.
If the solution doesnt make it any easier to avoid memory issues (just forces you to avoid them,) its not an attractive solution
Avoiding bugs is a pretty effective way to not have bugs.
Re: Regex: badly needs fuzzing
#13Google's cache of this bug (loads quite slowly for some reason): https://webcache.googleusercontent.com/search?q=cache:mVrrFL...
Text only link: http://webcache.googleusercontent.com/search?q=cache:https:/...
Re: Regex: badly needs fuzzing
#14Practical upshot: do not feed untrusted regexes into boost::regex.
Re: Regex: badly needs fuzzing
#15Google's cache of this bug (loads quite slowly for some reason): https://webcache.googleusercontent.com/search?q=cache:mVrrFL...
The trac instance (and legacy SVN server) isn't really designed for slashdot (well, HN) effect traffic, runs on some jiggly piece of rust at some uni somewhere.
Re: Regex: badly needs fuzzing
#16Another counterexample to the idea that modern C++ written by experts is free of memory safety issues.
Not that I necessarily think it'd avoid the problem even then, but I wouldn't call this modern C++ exactly. For one thing, it's (c) 2002, so written in C++98. And for another, it looks very uh, C-ish (not that uncommon in the C++98 era). In the bad sense of lots of error-prone pointer-based string manipulation, stuff like this:
if(STR_COMP(s1, p) >= 0)
{
do{ ++p; }while(*p);
++p;
if(STR_COMP(s1, p) isnot ? next : ++next;
}Re: Regex: badly needs fuzzing
#17They seem to be fuzzing the regex, not just the input it is applied to. This may or may not change the results, but if you're allowing users to input arbitrary regex patterns you have a whole lot of other problems.
Huh? It would be perfectly valid to have it power the regex part of the scripting engine in a browser, for example. If that would then lead to memory safety errors, you just got yourself a 0-day.
Regex engines used in browsers are both fast and hardened against these attacks.
Re: Regex: badly needs fuzzing
#18They seem to be fuzzing the regex, not just the input it is applied to. This may or may not change the results, but if you're allowing users to input arbitrary regex patterns you have a whole lot of other problems.
I've seen plenty of places that you may want to accept an arbitrary regex from the user. An app could allow the user to set up a filter for messages or usernames by putting in a regex. Or an interpreter for a sandboxed language could provide regex support.
Re: Regex: badly needs fuzzing
#19Any rust lovers out there: Could I ask you do a benchmark comparison and a fuzz comparison. I'd be genuinely interested in the result and if (as you might hope) the Rust::regex is as fast as boost:regex, and never crashes, that would persuade at least me to finally learn some Rust!
You can look at a well known (but not very complete) benchmark comparison here [0], rust wins, the fastest boost program is c++ g++ #3 and takes 8.5 times as long, the fastest c++ implementation (using re2) takes twice as long.
I don't know of a fuzz comparison, but there has been fuzzing done on the rust library without finding anything bad, e.g. see this issue [1].
[0] http://benchmarksgame.alioth.debian.org/u64q/performance.php...
Re: Regex: badly needs fuzzing
#20Any rust lovers out there: Could I ask you do a benchmark comparison and a fuzz comparison. I'd be genuinely interested in the result and if (as you might hope) the Rust::regex is as fast as boost:regex, and never crashes, that would persuade at least me to finally learn some Rust!
If you were interested in performance you probably would not have been using boost::regex to begin with. RE2 is often an order of magnitude faster. You might choose boost if you require backtracking, but that's crazy anyway due to exponential time.
What is backtracking?