[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <51D0B330.8010301@redhat.com>
Date: Sun, 30 Jun 2013 16:37:36 -0600
From: Kurt Seifried <kseifried@...hat.com>
To: oss-security@...ts.openwall.com
CC: Alexandre Rebert <alexandre.rebert@...il.com>, coley@...re.org,
Russ Allbery <rra@...nford.edu>, cve-assign@...re.org
Subject: Re: 1.2k bug reports for Debian, some may be security
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 06/27/2013 09:04 PM, Alexandre Rebert wrote:
> Hi,
>
> I can confirm most of the bugs have no security implications, and
> should probably not get CVEs. Given the high number of crashes we
> found, it is highely likely that some will impact security though.
Please let me know about this laong with impact/etc so I can confirm
they are security related. It's probably easiest to either post the
CVE requests here if the issue is public, if it needs to be private I
suggest using distros@ or emailing me directly. I would also ask that
you notify distros@ of security issues in any event so vendors can
coordinate releases. For more info people see:
people.redhat.com/kseifrie/CVE-OpenSource-Request-HOWTO.html
> Mayhem considered multiple input sources during the analysis of
> the 23K binaries: environment variables, command line arguments,
> files and standard input. Sockets was not one of them. That means
> that we only need to consider two attack vectors: (1) crashes of
> setuid/setgid programs, and (2) crashes with input files that are
> potentially untrusted.
>
> For (1), I have not checked whether we found crashes in
> setuid/setgid programs yet. It is however straightforward to
> compile a list and forward it to whoever is filing the CVEs. They
> might not be exploitable, but a crash in such programs is
> concerning and might be worth a CVE. Let me know if that's
> something you'd like us to do.
>
> For (2), it is difficult to automatically identify such crashes.
> As Steve mentioned, it may require a deep familiarity with the
> program. Package maintainers or upstream developers are the most
> suited people to judge whether a crash should be considered
> security critical. It is an unsatisfying solution, as the burden to
> report vulnerabilities would lie on them, but I don't see a way
> around it.
It's the most efficient, I mean Fedora/Debian/etc all have thousands
(Debian is 50k?) packages, that's a lot of software, asking security
researchers to be intimately familiar with it isn't realistic. Plus
most Open Source upstreams want to secure their code and won't mind
(usually).
>> I was under the impression from an incomplete read of the MAYHEM
>> paper that it could generate shellcode for code execution, yet
>> I'm only hearing of reports for crashes. If code execution can
>> be proven, then that may be informative.
>
> Yes, that is correct. Mayhem actually generated a couple of
> exploits from the crashes we found. We are currently looking at
> them individually, and we will report all exploits that are
> security issues.
>
> Regards, The Mayhem Team
>
- --
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
iQIcBAEBAgAGBQJR0LMvAAoJEBYNRVNeJnmTiKAP/j3MKZOdarSXWFttCWSKCOZd
kxnzm6TJBOD7llMxAE7d6ftEolN3o26bqKBtAxKRKwHyv7KUxBokrTPRsIu5sYjk
HckD8T/kJebjHxlxH6LeXEhYWyYvudjnX5gKBfnFkNim9VdvQ73xnQ6Ea+MzSebq
Dr4uo6PkxvGNPpZCQCc4NAlWJ/Z1xS5s1SbG1ukkhyGlBJ+NmU6DGbWEvN5oQe/C
WR8xJrQgt6AnttmgzMMTmDwxWwUcZzOhb3CIORd7V3qLkEIRKJyG+Ncl13TL+lnn
5zAgR9gg/BC4zBWKXauwFZmGqX8S7Rf0709npSah5F2J2lXc90yhPz+TZvVyFjKM
DY0/OYIwdrU7kTpkXaUkVnQIN2xxQO5hg1JbAhAAW9Rj0eljJT8VRH97u2ZqfXtQ
a6AoqiCc2VTaU+guiZOvE2f5ys/cbrJc8TCZWqSSCH80uUqHjtNOQMs0AZjbkvLb
/5AszCFzjHbIhcP8NghqXvpQS+xOwURlertXD1ziaWNqcKedE2mYOEOVmEdK/oFb
HrZv6NwRd8y/AGCzgsPyjwtfuguRaiAjPBTpaA6D26RmCwutKtPr76U+UPFpIX4/
+YpZqUpJ7x7WzAzpFc56C0hJ1wPfk4MI6/Bqn5fkykp9WMgO/KV/PHZZG6+bxIPd
5NguP55neGGbZ4GZyO8N
=XbU4
-----END PGP SIGNATURE-----
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.
