linux-kernel - Re: buffer overflow in /proc/sys/sunrpc/transports

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <g9ca28$pak$1@taverner.cs.berkeley.edu>
Date:	Sat, 30 Aug 2008 20:20:24 +0000 (UTC)
From:	daw@...berkeley.edu (David Wagner)
To:	linux-kernel@...r.kernel.org
Subject: Re: buffer overflow in /proc/sys/sunrpc/transports

Vegard Nossum  wrote:
>I don't know if this could be used in some malicious way. Maybe if a setuid
>root program tried to open a user-supplied file (which could be this one in
>/proc), it could crash the program quite easily. But since there is no way
>to change the contents of the file... I don't know.

You don't necessarily need control over the values that are written past
the end of the buffer to exploit a buffer overrun bug.  If those values
are semi-random but predictable, it may still be possible to exploit the
vulnerability by arranging to stash malicious code at the address that the
return address will be overwritten with.  Even if those values are random
and not predictable, it may still be able to fill a large fraction of the
address space with malicious code and thus have a significant probability
of successful exploitation.  See, e.g., NOP sleds, heap spraying, heap
feng shui.  I would not want to rely on this bug being difficult to exploit.

Bottom line: I suspect it would be prudent to assume this bug may be
fully exploitable.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/