[12423] in bugtraq

home help back first fref pref prev next nref lref last post

Re: "Function pointer" attacks.

daemon@ATHENA.MIT.EDU (Mariusz Woloszyn)
Wed Nov 3 16:35:51 1999

Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-2
Message-Id:  <Pine.SGI.4.10.9911031453340.8734-100000@ikp.ikp.pl>
Date:         Wed, 3 Nov 1999 15:20:47 +0100
Reply-To: Mariusz Woloszyn <emsi@IT.PL>
From: Mariusz Woloszyn <emsi@IT.PL>
X-To:         vendicator@USA.NET
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To:  <19991101211407.25955.qmail@securityfocus.com>
Content-Transfer-Encoding: 8bit

On Mon, 1 Nov 1999 vendicator@USA.NET wrote:

> I don't know is this tecnique is already known but since I
> added a protection for it in Stack Shield I decided to post
> it.
> 

It is known for a long time. AFAIR it was described in StackGuard papers
and "w00w00 on Heap Overflows" by Matt Conover & w00w00 Security Team
(posted on BugTraq). Such kind of attack seems to be very rare!

(...)

> The new Stack Shield 0.6 beta has a new protection mechanism
> that checks on non-costant calls if the call is in the TEXT
> segment. This could cause problems for programs that execute
> code from the DATA or STACK segment, howewer this stops this
> kind of attack.
> 

I read so called "detailed info" of StackShield and i found it is
vulnerable to Frame Pointer Overwrite. It was described in Phrack Magazine
55 by klog.

Look at function prolog:

0x8048150 <f>:  pushl  %ebp
0x8048151 <f+1>:        movl   %esp,%ebp
0x8048153 <f+3>:        movl   0x805fb78,%eax
0x8048158 <f+8>:        cmpl   %eax,0x805fb74
0x804815e <f+14>:       jbe    0x8048165 <f+21>
0x8048160 <f+16>:       movl   0x4(%ebp),%edx
0x8048163 <f+19>:       movl   %edx,(%eax)
0x8048165 <f+21>:       addl   $0x4,0x805fb78
0x804816c <f+28>:       subl   $0x28,%esp

and epilog:

0x80481cd <f+125>:      addl   $0x4,%esp
0x80481d0 <f+128>:      addl   $0xfffffffc,0x805fb78
0x80481d7 <f+135>:      movl   0x805fb78,%ebx
0x80481dd <f+141>:      cmpl   %ebx,0x805fb74
0x80481e3 <f+147>:      jbe    0x80481ea <f+154>
0x80481e5 <f+149>:      movl   (%ebx),%edx
0x80481e7 <f+151>:      movl   %edx,0x4(%ebp)
0x80481ea <f+154>:      movl   %ebp,%esp
0x80481ec <f+156>:      popl   %ebp
0x80481ed <f+157>:      ret    


So it first checks the integrity of ret then pop-s saved ebp.
I'm afraid it is the real bug that can be exploited.

Anyway, as I can see that cost of execution StackSielded programs appears
to be bigger than StackGuarded ones. Is there any paper about StackShield
performance?

--
Mariusz Wołoszyn
Internet Security Specialist, Internet Partners, GTS Poland
E-mail: emsi@it.pl

home help back first fref pref prev next nref lref last post