Re: Format String Attacks

[Iván Arce <core.lists.bugtraq () CORE-SDI COM>]

Hi Tim,
 a minor comment about the paper...

Tim Newsham wrote:
> The value that "%n" wrote to x was 504, much larger than the 99 characters
> actually emitted to buf. We can provide arbitrarily large values by just
> specifying a large field width [1]. And what about small values? We can
> construct arbitrary values (even the value zero), by piecing together
> several writes. If we write out four numbers at one-byte offsets, we can
> construct an arbitrary integer out of the four least-significant bytes. To
> illustrate this, consider the following four writes:
>
>     Address        A   A+1  A+2  A+3  A+4  A+5  A+6
>     Write to A:   0x11 0x11 0x11 0x11
>     Write to A+1:      0x22 0x22 0x22 0x22
>     Write to A+2:           0x33 0x33 0x33 0x33
>     Write to A+3:                0x44 0x44 0x44 0x44
>     Memory:       0x11 0x22 0x33 0x44 0x44 0x44 0x44
>
> After the four writes are completed, the integer value 0x44332211 is left
> in memory at address A, composed of the least-significant byte of the four
> writes. This technique gives us flexibility in choosing values to write, but
> it does have some drawbacks: It takes four times as many writes to set the
> value. It overwrites three bytes neighboring the target address. It also
> performs three unaligned write operations. Since some architectures do not
> support unaligned writes, this technique is not universally applicable.

This was mentioned in the incidents mailing list, regarding the ability
to exploit the wu-ftpd problem on Sparc, the following is a quote of
Juliano Rizzo's post on the matter

http://www.securityfocus.com/archive/75/79854

> On 31 Aug 2000, Fyodor wrote:
>
>
> > Generally speaking formatted string vulnerabilities are _NOT_ exploitable
> > on sparc platforms they way they are being exploited nowdays on x86.
>
> That's not true, format string bugs are exploitable on sparc with a little
> variation of x86 or other archs exploits.
>
> > problem is due to alignment requirements you can not shift the address
> > per-byte to write return address,
>
> It isn't necessary to write the return address byte per byte. I think the
> best method to write it, is using short ints, then you need only two
> addresses to write to and the align isn't any problem. In this way you
> avoid the next problem too:
>
> > and due to libc limitations (at least on
> > solaris7 and 2.6) you can not write more than 4fc (last time I
> > checked) bytes per-call, which means that you can not place higher
> > address. (anyone who can prove that I am wrong, I'd be happy to hear this,
> > honest! :))
>
> Well, I imagine  you are trying to write the ret address with 4 %n
> I dislike that method. I don't understand the 0x4FC limitation may be
> you are using something like %.1277d and your printf implementation
> overflows with long  precision fields. You could try with %1277c.
>
> Btw, the format strings exploits looks better if you use the $ conversion
> form and %hn.
> To exploit usfs on sparc may be you should take attention to: big endian
> byte order, memory aligment (but isn't a problem) and printf
> implementation (problems with $ and printf's overflows)


-ivan

--
"Understanding. A cerebral secretion that enables one having it to know
 a house from a horse by the roof on the house,
 It's nature and laws have been exhaustively expounded by Locke,
 who rode a house, and Kant, who lived in a horse." - Ambrose Bierce


==================[ CORE Seguridad de la Informacion S.A. ]=========
Iván Arce
Presidente
PGP Fingerprint: C7A8 ED85 8D7B 9ADC 6836  B25D 207B E78E 2AD1 F65A
email   : iarce () core-sdi com
http://www.core-sdi.com
Pte. Juan D. Peron 315 Piso 4 UF 17
1038 Capital Federal
Buenos Aires, Argentina.              Tel/Fax : +(54-11) 4331-5402
Casilla de Correos 877 (1000) Correo Central
=====================================================================

--- For a personal reply use iarce () core-sdi com