bugtraq - Possible memory corruption problems in Apple Safari

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20050917030734.GA9837@jrock.us>
Date: Fri, 16 Sep 2005 22:07:34 -0500
From: Jonathan Rockway <jon@...ck.us>
To: bugtraq@...urityfocus.com
Subject: Possible memory corruption problems in Apple Safari

Hello,

I was playing around with Safari the other day and noticed that it
crashes solid if you convince it to visit:

data://<h1>crash</h1>

Typing it into the address bar is sufficient for testing and crashes
the browser completely.  I loaded up Safari in gdb to see where it
crashes and got the following result:

> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_INVALID_ADDRESS at address: 0x076fffff
> [Switching to process 266 thread 0x6403]
> 0xffff8ce4 in ___memcpy ()

The fact that random data from the Internet is causing problems with
memcpy worries me.  I haven't figured out how to change the arguments
to memcpy, but it seems possible.  Hopefully someone that knows more
about debugging threaded Objective-C programs running on PPC can
look into it.  I'm more of a simple x86/C person myself :)

Just for reference, it seems that Safari needs a very specific set of
inputs to actually crash:

data://<h>/ doesn't crash
but
data://<h>/< does

(also data://<crash>test</crash> doesn't crash... the h in <h1> seems
important somehow).

Regards (and good luck),
Jonathan Rockway