full-disclosure - THREATCON HITTING DANGEROUS LEVELS!

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-next>] [day] [month] [year] [list]

Message-ID: <20020929220336.A6341@hamsec.aurora.sfo.interquest.net>
From: silvio at big.net.au (silvio@....net.au)
Subject: THREATCON HITTING DANGEROUS LEVELS!

THREATCON(tm) has taken a dramatic turn in recent days.

90% of YOUR system binaries are vulnerable according to new market research.

To quote some success stories -->

"I had talked about IT before, with the others.  so when IT hit us, we
were ready".

I dont think they knew what IT was to be honest, but threatcon is a graphical
frontend to a highly innovative, technologically pioneering advanced
software, engineered to meet todays requirements and has become the solution
for the enterprise space.

After some market analysis and trendy ROI talk, with partners and alliances,
of industry leaders -->

#include <stdio.h>
int main(int argc, char *argv[]) { char *v[] = { NULL };
execve(argv[1], v, NULL); }

^^ this is from memory, not cut&paste, so hopefully I dont have too many
bugs.. gotta check argv I think in the future :(
hope execve doesnt fail in the above :(

try it on your favourite binaries -
	/bin/at
	/bin/basename
	/usr/bin/comp
	/usr/bin/dialog
	/usr/bin/env
	/usr/bin/file
	/usr/bin/gzip

there really are a massive number of binaries that will segv.  i stopped
taking note after the 200'th one or so.

-- to be serious 

This is of course, not really a security threat by any means.. It is an
annoying bug that effects alot of things and is really not handled
correctly in the majority of implementations.

I did only test the above on Linux.
A large majority of binaries segv' ofcourse due to dereferencing argv[0]
(who the hell checks argv[0] == NULL ?). 
In Linux (and probably most), NULL argv0 is acceptable, which breaks nearly
everything that uses it in userland.

Alot of programs that do things like printf("Usage: %s ...\n", argv[0])
are probably going to crash dependant on libc.  For glibc, printf' NULL
strings will not be dereferenced, and hence wont segv.
A number of programs also do things like strcmp(argv[0],
to determine the context of execution.  These are almost certain to crash.

It may be appropriate to implement simple sanity checking for argv[0] in
kernel space, as there really is just too much userland code that does not
work correctly if it is set null.

(ok.. sorry for making light humour of all of this, but thats what light
humour is for these days, especially when laws, regulation, and politics get
involved).

--
Silvio