Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 23 Jan 2013 18:49:37 -0700
From: Vincent Danen <>
Subject: Re: CVE Request coreutils

* [2013-01-23 08:47:35 +0100] Sebastian Krahmer wrote:

>On Tue, Jan 22, 2013 at 08:47:46AM -0700, Vincent Danen wrote:
>> * [2013-01-22 08:25:23 +0100] Sebastian Krahmer wrote:
>>> Generally, I see your point. However sometimes services running as
>>> root 'sort' or 'uniq' user input e.g. via grepping logfiles etc,
>>> so there is indeed a real chance to indirectly trigger a privilege
>>> escalation. The past shows that segfaults can be turned into a
>>> code exec often. Its a stack overflow after all.
>> Do you believe this would be the case with modern GCC/Glibc hardening
>> though?  Wouldn't this just be rendered a crash?
>Are you serious? And since when will CVE's not be assigned because
>some mitigation could possibly prevent a stack overflow being turned
>into code exec?

Sorry, I should have perhaps clarified that a bit more.  That wasn't so
much to say "don't assign a CVE" as much as a "is this mitigation
sufficient".  I can see, however, how it might have been construed the
other way.

>> But even then, if we're talking about logfiles (which is a reasonable
>> case) you'd have to be allowing user-controlled input to your logs,
>> which would mean you'd have another problem.
>You mean like 'logger -t sshd failed login attempt' ?

Yes, indeed, exactly like that.  =)  Although one would hope that logger
has a decent input limit where you couldn't inject a ~10MB long line
into syslog.  Regardless, what logger does or doesn't do isn't the issue

>> I'm also assuming, based on the comments in the first bug, that you need
>> a really large line (not just an entire file, but one line).  How likely
>> is it that you would be grepping a log file with ~10MB of data on one
>> line?
>Not very common indeed, but I think its not the point (logfiles were
>just _one_ example).

Yes, absolutely.

>Nevertheless, you seem to shift your arguments. For each reason/attack vector
>I answer, you bring up two new reasons why this not an issue.
>At the end, I did not spot the bug; if the majority thinks its not worth
>a CVE, I can live with it. It would just have made tracking easier.

You're right.  I'm inclined to think it isn't an issue (or at least not
one really worth filing bugs over, however that is just my personal
opinion).  I see that Kurt did indeed assign CVEs, so I'll be filing
those bugs regardless.

>PS: Reminds me to the one-year dbus discussion where everyone told me that
>this can never be a problem.

You, sir, have a very valid point here.  Thanks for that little

Vincent Danen / Red Hat Security Response Team 

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.