[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#22838: New 'Binary file' detection considered harmful

From: Paul Eggert
Subject: bug#22838: New 'Binary file' detection considered harmful
Date: Mon, 29 Feb 2016 11:29:24 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0

On 02/29/2016 09:14 AM, Marcello Perathoner wrote:
Keeping the old bug is far wiser than to fix it and introduce a new bug.

That depends on the bugs in question. The old bugs were pretty bad.

Copying faulty input to the output is a preferable failure mode

Again, we cannot satisfy everybody. There are reasonable complaints from users if 'grep' blasts improperly-encoded data to their terminals, or more generally if grep's improperly-encoded output trashes other programs that read the output. This is why grep has the -a option. It sounds like you need grep's -a option for your application, and it should be easy to use -a. It's not clear that -a should be the default.

any process that feeds tainted (user-provided) strings to grep can now be made to fail. Eg. a process that greps apache logs for known exploit signatures will now fail if the attacker sends a bogus user-agent string.

Such a process won't fail if it uses grep's -a option, or if it treats the "Binary file matches" diagnostic as an indication that there are possible attacks, or if it is run in a unibyte locale where all bytes are valid characters, or if it looks at grep's exit status. Granted, slapdash approaches that don't do any of these things will be vulnerable, but they'll be vulnerable even with older grep versions.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]