>The kernel patch makes no such compromise. As near as I can tell, it is
>completely performance neutral, and largely transparent. The only compromise
>is that special handling for signal delivery is required, which the kernel
>patch provides.
Is it possible with the Linux kernel patch to stil
> Aleph, please kill my article if someone else says it better/first. I've been
> waiting in silence for Solar Designer to speak up and end the debate about how
> to do this, but I guess he's away from his e-mail.
I was simply unsure if we really need to repeat this discussion (it's
been on the
Crispin Cowan wrote:
> > > I think one of the major problems with the Linux implementation, and
> > > apparently windows too, is that noone pays attention to the added security
> > > provided by segmentation (at least to the point of putting the stack on a
> > > different segment?)
> >
> > Having
Hi!
> The 386 and up supports no-exec, but only on differing segments. Most OS
> systems aren't properly implemented on the 386+ architecture. The 386+
> supports read-only pages in the paging architecture, but to separate
> executable code from stack and data, you have to point the segment
> r
Aleph, please kill my article if someone else says it better/first. I've been
waiting in silence for Solar Designer to speak up and end the debate about how
to do this, but I guess he's away from his e-mail.
Glynn Clements wrote:
> Christopher Rhodes wrote:
> > I think one of the major problems
- Original Message -
From: Glynn Clements <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, November 27, 1999 7:22 AM
Subject: Re: WordPad/riched20.dll buffer overflow
> Christopher Rhodes wrote:
>
> > I think one of the major problems with the L
Christopher Rhodes wrote:
> I think one of the major problems with the Linux implementation, and
> apparently windows too, is that noone pays attention to the added security
> provided by segmentation (at least to the point of putting the stack on a
> different segment?)
Having separate non-over
The 386 and up supports no-exec, but only on differing segments. Most OS
systems aren't properly implemented on the 386+ architecture. The 386+
supports read-only pages in the paging architecture, but to separate
executable code from stack and data, you have to point the segment
registers at dif
I seem to recall a Linux kernel guru explaining that the x86 MMU doesn't actually
support non-exec pages, or some such. It doesn't support it, or it just doesn't
work right. I remember bringing up the issue of noexec and that was the answer.
--Perry
> Ok, here it is, on page 58, it's talki
Solar Eclipse wrote:
> When I tried this, I found out that code CAN be executed on the heap,
> although the heap descriptor has no execute permissions. I don't know
> why. If somebody can confirm this it would be great.
I remember reading something about this i a book named Windows NT Device
Solar Eclipse wrote:
> Just find me a single RET instruction and I will rule the world!
'ldkw' == 0x776B646C, in my NT4SP3 is a RET 8 [C2 08] in WS2_32.dll, the
address we wish to return (the one in the heap you [Solar] said) would be
reachable with this RET 8, and I managed to use this RET
Well, I find SOME ways to CRASH (no exploit possibly), in another place in
the format rft, in the richie20.dll, making a EATER OF STACK,
Inside in the rtf file,
One rtf inside of another with OLE, the ole(wordpad), crash , with a STACK
OVERFLOW EXCEPTION FILTER,
EXAMPLE RTF CODE:
{\rtf1\ansi\an
At 06:57 PM 11/22/1999 -0600, Solar Eclipse wrote:
>Mnemonix wrote that the shell code is not lowercased on Win2K. Are there
>any other restrictions? Can you use characters > 128 ?
>
>What about Win9x?
>
>Are there any DLLs loaded in the 6161616-7A7A7A7A range on there
>machines?
Only alphabetic
On Sat, 20 Nov 1999 00:43:26 -, Mnemonix wrote:
>This is exploitable. On both Windows NT4 and Windows 2000 the payload can be
It is not. As seen from the posts by USSR labs and Solar Eclipse as well as from
my analysis on the vuln-dev list we can safely say that the DLL is not exploitable
u
- Original Message -
From: "Thomas Dullien" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; "Mnemonix" <[EMAIL PROTECTED]>
Sent: Tuesday, November 23, 1999 12:53 PM
Subject: Re: [BUGTRAQ] WordPad/riched20.dll buffer overflow
>
> On Sat, 20 Nov 19
On Sat, 20 Nov 1999 00:43:26 -
Mnemonix <[EMAIL PROTECTED]> wrote:
> This is exploitable. On both Windows NT4 and Windows 2000 the payload can be
> found at the ESP - but there is a difference between the two OSs.
> NT 4 seems to do a tolower() on the string turning "" to "" where as
- Original Message -
From: "Gerardo Richarte" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, November 18, 1999 9:45 PM
Subject: Re: WordPad/riched20.dll buffer overflow
> I've been trying to determine if it's exploitable, and couldn'
I kindly suggest using a fixed width font for your viewing pleasure.
Microsoft Wordpad Buffer Overflow
I. Introduction
The first report was from Pauli Ojanpera <[EMAIL PROTECTED]>
Win98/NT4 Riched20.dll (which WordPad uses) has a classic buffer
overflow problem with ".rtf"-fi
Well i work in the exploit of the WordPad/riched20.dll buffer overflow, and
i have to say something bad, IT CANT BE EXPLOITABLE FOR TWO REASONS.
1: the filter of the riched20.dll, only accepts letters from "a" to "z" or
"A" TO "Z", that says you only can
> Just if someone needs to know...
>
> Win98/NT4 Riched20.dll (which WordPad uses) has a classic buffer
> overflow problem with ".rtf"-files.
>
> Crashme.rtf :
> {\rtf\}
>
> A malicious document may probably abuse this to execute arbitary
> code. Wor
This bug is also present in Microsoft's flagship operating system Windows
2000
On Thu, 18 Nov 1999, Pauli Ojanpera wrote:
> Just if someone needs to know...
>
> Win98/NT4 Riched20.dll (which WordPad uses) has a classic buffer
> overflow problem with ".rtf"-files.
>
> Crashme.rtf :
> {\rtf\AA
Pauli Ojanpera wrote:
>
> Just if someone needs to know...
>
> Win98/NT4 Riched20.dll (which WordPad uses) has a classic buffer
> overflow problem with ".rtf"-files.
>
> Crashme.rtf :
> {\rtf\}
>
> A malicious document may probably abuse this to exec
Just if someone needs to know...
Win98/NT4 Riched20.dll (which WordPad uses) has a classic buffer
overflow problem with ".rtf"-files.
Crashme.rtf :
{\rtf\}
A malicious document may probably abuse this to execute arbitary
code. WordPad crashes with
23 matches
Mail list logo
