Home page logo
/

bugtraq logo Bugtraq mailing list archives

Re: Format String Attacks
From: Iván Arce <core.lists.bugtraq () CORE-SDI COM>
Date: Tue, 12 Sep 2000 00:23:05 -0300

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


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]