[12423] in bugtraq
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