Does This Scare You?

[Steve D'Aprano]

On Mon, 22 Aug 2016 09:50 pm, Jon Ribbens wrote:

> On 2016-08-22, Chris Angelico <rosuav at gmail.com> wrote:
>> On Mon, Aug 22, 2016 at 8:33 PM, Jon Ribbens <jon+usenet at unequivocal.eu>
>> wrote:
>>> On 2016-08-22, Steve D'Aprano <steve+python at pearwood.info> wrote:
>>>> On Mon, 22 Aug 2016 10:38 am, eryk sun wrote:
>>>>> To me it's scary that this check misses cases because it's trying to
>>>>> be cross-platform instead of simply relying on GetFullPathName to do
>>>>> the work. For example, it misses at least the following cases:
>>>>
>>>> Instead of shaking in your boots over a simple bug in a non-critical
>>>> library, how about reporting these cases on the bug tracker with an
>>>> explanation of the problem?
>>>
>>> That seems a rather unnecessarily harsh response.
>>> Also, it's not "non-critical", this is a security bug.
>>
>> Explain how?
> 
> I don't know what purpose you are envisaging this function being used
> for, but the only one I can think of is input sanitisation. e.g. a web
> form where you receive a file from the Internet and store it somewhere,
> and you want to use the filename given to you rather than choose your
> own randomly-generated one.
> 
> Under Unix all you need to do is check for the filename starting with
> "." or containing "/." (or "/", depending on your requirements).
> Under Windows you would use this function, which apparently doesn't
> work, hence: security hole.

That's backwards: it works under Windows, but is buggy under non-Windows.

In any case, I don't think that what you suggest is even close to
sufficient.

For starters, even on Unix I probably wouldn't want to
use "\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\.txt" as a
file name, even if it is technically legal. Nor would I allow 

"foo.jpg                                                                                                                                                                                                   .exe"

either, especially not on Windows.

But let's suppose my application can handle newlines and other control
characters in filenames (I never `ls` the storage directory, all my scripts
are newline safe, etc.) And I don't care about users uploading malware with
disguised file names. Am I done?

No, not at all. I can't assume that just because a file name is legal that I
can write to it. Even after sanitising the name (or deciding I don't need
to bother) I still need to be prepared to catch I/O errors when writing the
file -- including attempts to write to reserved file names.

None of this makes the issue a security issue. How would you exploit it? The
attacker would have to ensure that the file name is sanitised under Linux
but then written to a file under Windows, in which case the worst that
happens is that I get an unexpected I/O error.

Technically that could be called a DoS attack, but the same could be said
for ANY bug that raises an exception. I think that it takes more than that
to be a security bug.



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.