[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121017175839.GD2630@sentinelchicken.org>
Date: Wed, 17 Oct 2012 10:58:39 -0700
From: Tim <tim-security@...tinelchicken.org>
To: oss-security@...ts.openwall.com
Subject: Re: CVE request: ruby file creation due in insertion
of illegal NUL character
> It's difficult to reason about whether this is a bug or a feature
> without knowing the justification for treating the Ruby version as a
> security vulnerability, which was not included in the announcement.
>
> One possible justification is this: suppose a webapp writes files with
> an attacker-controlled name to the web-server-visible /uploads/
> directory, using this pseudocode:
>
> if (filename ends with .jpg) {
> open_for_writing(filename).write(content)
> }
> else {
> error "that's not a JPEG, go away"
> }
>
> and suppose that the web server also executes *.php files in that
> directory. Then an attacker could upload "evil.php\0.jpg", and browse
> to http://example.com/uploads/evil.php to get their payload executed.
>
> Is this what the Ruby people had in mind, or is there some other
> attack vector I'm not seeing?
I've personally exploited this condition in a number of PHP apps
during pentests (in versions of PHP that don't prevent it).
Is the application at fault for not doing a better job of data
validation? Yes. Yet, is there any good reason to allow raw NUL
bytes in file names? NO. As mentioned, no filesystem supports it.
You can save the average web app user a lot of grief by just rejecting
blatantly illegal paths.
tim
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
