On 6 Feb 2002, keoki wrote:
> A problem exist in FreeBSD's version of SED, that when you specify
> last line and do not get contents of hold area and then delete the
> first part of a pattern space against a file which contains two lines
> or more, it results in a Segmentation fault "coredump".
this is confirmed on openbsd-current using a debugging version of sed
(built with -g):
$ uname -a
OpenBSD tank 3.0 TANK#1 i386
$ for i in 1 2; do echo "blah" >> example; done
$ which sed
./sed
$ ldd sed
sed:
-lc.28 => /usr/lib/libc.so.28.2 (0x40022000)
$ file sed
sed: OpenBSD/i386 demand paged dynamically linked executable not stripped
$ sed '$!g; D' example
Memory fault (core dumped)
$ sed '$g; D' example
Memory fault (core dumped)
it dies in process.c (called at main.c:155) for the same reasons you
specify.
however, i fail to see why this is a potential vulnerability. surely
you're not allowing sed to be called on untrusted input (ie on a web
server), or the like. and while sed is sometimes called as root (ie in a
makefile installation), you're already open to far more avenues of attack
than a sed issue. can you illustrate a plausible attack using this?
this is a reliability issue, yes, and it should be handled gracefully in
the code. i have Cc'd openbsd's bug list with this, i suggest you report
this to freebsd's bug handlers, too, as a reliability issue of low
priority.
____________________________
jose nazario joseat_private
PGP: 89 B0 81 DA 5B FD 7E 00 99 C3 B2 CD 48 A0 07 80
PGP key ID 0xFD37F4E5 (pgp.mit.edu)
This archive was generated by hypermail 2b30 : Wed Feb 06 2002 - 10:11:47 PST