On Tue, 7 Mar 2000, Lamagra Argamal wrote:
> On FreeBSD dump has the same hole i describes in my previous post.
> Only it is exploitable :-) Dump with kerberos has __atexit and
> __cleanup after all the other variables on the heap. By overwriting
> these variables you can start your shellcode.
>
In message <[EMAIL PROTECTED]> Lamagra Argamal writes:
: On FreeBSD dump has the same hole i describes in my previous post. Only it is
:exploitable :-)
You are wrong. That hole was cleaned up a long time ago, before
Release 3.3R. Are you *SURE* that you tested a latest version?
Warner
On Tue, Mar 07, 2000 at 09:14:32PM -, Lamagra Argamal wrote:
> On FreeBSD dump has the same hole i describes in my previous post. Only it is
>exploitable :-)
but on freebsd, dump is only sgid tty.
--
* Fido: 2:480/124 ** WWW: http://www.freebsd.lublin.pl ** NIC-HDL: PMF9-RIPE *
* Inet: [EMA
On FreeBSD dump has the same hole i describes in my previous post. Only it is
exploitable :-)
Dump with kerberos has __atexit and __cleanup after all the other variables on the
heap. By overwriting these variables you can start your shellcode.
Most of the credits should go to zen-parse who foun
On 02-Mar-2000 Derek Callaway wrote:
> I believe this overflow is rather difficult to exploit, (although, not
> impossible) as a result of a setuid(getuid()) before the offending code
it does setuid(), but NOT setgid(). still vulnerable.
the major problem is how to pass valid **envp to stack and
i checked RedHat's 5.2 dump (dump-0.3) and it doesn't seem vunerable in an exploitable
way.
There's a minor heap-overflow though:
snipped from optr.c
msg(const char *fmt, ...)
{
...
va_start(ap, fmt);
#else
va_start(ap);
#endif
(void) vfprintf(stderr, fmt, ap
>No. getenv() fails because *envp, argc, **argv are AFTER
>pathname[]
>buffer and gets overwritten.
>Of course, it is still exploitable.
It doesn't quite look that way to me.
The overflow takes place after the setuid(getuid()) call has
been made. Which renders execution of shellcode useless to
On Fri, 3 Mar 2000, Eugene Teo wrote:
> server running Redhat 6.1 doesn't seem to be vulnerable to this. Like
Not true -- RedHat is vulnerable. The example given by KimYongJun shows an
overflow with only 556 characters. 556 bytes doesn't seem to overflow the
RedHat version of dump; it only prod
This is the same behavior as all my OpenBSD 2.6-Release boxes. /sbin/dump
is also not SUID/SGID on these systems by default.
--
Joseph W. Shaw - [EMAIL PROTECTED]
Free UNIX advocate - "I hack, therefore I am."
On Wed, 1 Mar 2000, Brett Lymn wrote:
> NetBSD-current, at least, is not vulnerable
On 01-Mar-2000 Derek Callaway wrote:
> (gdb) #0 getenv (name=0x40111a70 "") at ../sysdeps/generic/getenv.c:88
>>From this gdb session, it appears that there _could_ be a problem with
> the way that glibc's time functions behave.
No. getenv() fails because *envp, argc, **argv are AFTER pathname[]
ssage -
From: ±è¿ëÁØ KimYongJun (99Á¹¾÷) <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, February 28, 2000 2:17 PM
Subject: [ Hackerslab bug_paper ] Linux dump buffer overflow
> [ Hackerslab bug_paper ] Linux dump buffer overflow
>
>
> File : /sbin/dump
&g
According to "KimYongJun":
>
>File : /sbin/dump
>
>SYSTEM : Linux
>
>
NetBSD-current, at least, is not vulnerable to this. It just returns
a filename too long error. I do not have a release version of NetBSD
to try this on at the moment.
--
===
Hi,
Confirmed this on SuSE 6.2. The magic number of bytes is 347. Dump is
not su/gid so this seems to be more of an annoyance than a security
issue for SuSE boxen (not sure of others).
-HD
"±è¿ëÁØ KimYongJun (99Á¹¾÷)" wrote:
>
> [ Hackerslab bug_paper ] Linux dump buffer ov
On Mon, 28 Feb 2000, ±è¿ëÁØ KimYongJun (99Á¹¾÷) wrote:
> [ Hackerslab bug_paper ] Linux dump buffer overflow
>
> [loveyou@loveyou SOURCES]$ dump -f a `perl -e 'print "x" x 556'`
> DUMP: Date of this level 0 dump: Mon Feb 28 14:45:01 2000
> DUMP:
[ Hackerslab bug_paper ] Linux dump buffer overflow
File : /sbin/dump
SYSTEM : Linux
INFO :
The problem occurs when it gets the argument.
It accepts the argument without checking out its length, and this causes the problem.
It seems that this vulnerability also applies to RedHat
15 matches
Mail list logo
