well it's over
Finlay Dobbie
-- Finlay
mart...@gmail.com
of BS, and were not related to Apple anyway.
burn.red...@gmail.com
> moab 1 was not bad, Apple fixed it, most of the other bugs were a load
> of BS, and were not related to Apple anyway.
Actually, about 21 of them were Apple issues, although admittedly
there was a fair bit of overlap/similarity among many of them
(permissions related attack vectors, format string vulnerabilities
etc).
vntgntks
I got the spinning beach ball several times when reading 29. Is it
possible that something was planted on my Mac while that ball was
spinning?
Richard
William A. Carrel
there's a CVE number assigned now so it should have had some amount of
review by a CNA. Maybe they're giving Apple another chance going down
the vendor notification route rather than the zero-day route. Being
left hanging like this when you know a problem is looming can be quite
frustrating, but just imagine for a moment, you're the researcher who
discovered the problem and the vendor is treating you this way about
whether they're even looking at the issue, let alone developing or
testing a fix.
At the risk of writing a novel here, my own personal hope is that
Apple and its user community can foster better relations with the
people finding and fixing security problems in the future. Step one,
communicate _collaboratively_ since everybody wants better security at
the end of the day. (Corollary to step one, don't claim that
everything is a non-issue for some contrived reason and that everyone
but you is obviously an idiot.) Talented folks volunteering to lend OS
X programming/reversing skills where available to a project like ZERT
could also be a real win if they're interested.
Back to your post... the beachball was due to an embedded JPEG2000
graphic that CoreGraphics can't deal with. (see previous thread at
http://groups.google.com/group/moabfixes/browse_thread/thread/041c76ee5cbadc74?hl=en)
jpel...@gmail.com
Rosyna
QuickTime plugin passes off the Javascript to the browser (because QT
itself doesn't have a javascript runtime and even if it did, it
wouldn't have access to the DOM). The browser isn't properly checking
the domain of the file that loaded the plugin, instead assuming it is
in the same domain as the parent frame. This allows for a cross site
scripting attack. If you look at the moab #3 issue, it explicitly
mentions this bug in IE. It just so happens to be a common bug in IE,
Opera, and Firefox. Bugs have been filed on Opera and Firefox.
Note that the currently released Safari is not a vector for attack.
Ack, at 2/2/07, jpel...@gmail.com said:
>Did the Apple QT security update fix only #1 or #1 + #3?
--
Sincerely,
Rosyna Keller
Technical Support/Carbon troll/Always needs a hug
Unsanity: Unsane Tools for Insanely Great People
It's either this, or imagining Phil Schiller in a thong.
mart...@gmail.com
right, in fact only 7 are not related to Apple.
but most of these bugs are just that, bugs, not security issues, they
require access to the local machine, and rarely cause anything more
than a crash.
i did not read the details about all of them, but i checked a few,
MOAB 1 is supposed to allow you to execute code at a specific
location, i could not reproduce that, it executed code (bad enough),
but the program counter was not pointing to "deadbabe" as was
suggested.
there are thousands of similar bugs, most applications don't run well
when u open corrupted documents.
William A. Carrel
> On Feb 1, 1:08 pm, burn.redmond.b...@gmail.com wrote:
> > On Feb 1, 11:07 am, martij...@gmail.com wrote:
> >
> > > moab 1 was not bad, Apple fixed it, most of the other bugs were a load
> > > of BS, and were not related to Apple anyway.
> >
> > Actually, about 21 of them were Apple issues, although admittedly
> > there was a fair bit of overlap/similarity among many of them
> > (permissions related attack vectors, format string vulnerabilities
> > etc).
> right, in fact only 7 are not related to Apple.
>
> but most of these bugs are just that, bugs, not security issues, they
> require access to the local machine, and rarely cause anything more
> than a crash.
The continued characterization of potential problems with OS X and its
applications as "not real security issues, just a bug" does a
disservice to the people working to find them by insulting their work,
a disservice to the user community by keeping them ignorant, and a
disservice to developers by encouraging laziness. To quote Jon
Stewart, "Please stop, you're hurting America."
> i did not read the details about all of them, but i checked a few,
> MOAB 1 is supposed to allow you to execute code at a specific
> location, i could not reproduce that, it executed code (bad enough),
> but the program counter was not pointing to "deadbabe" as was
> suggested.
There is a variety of interesting work that has been done about
targeting exploit code like this.
Linux, OpenBSD and Windows Vista share an interesting related feature
called "address space layout randomization," such that it loads the
pieces of programs into memory in a random fashion in order to make
guessing attack vectors much harder. There is a blog post about it
here: http://blogs.msdn.com/michael_howard/archive/2006/05/26/address-space-layout-randomization-in-windows-vista.aspx
There is also a good wikipedia entry about it here:
http://en.wikipedia.org/wiki/ASLR
It would be nice to see Apple include this in a 10.5.x or 10.6 release
since it makes it somewhat harder to do something useful with injected
code.
> there are thousands of similar bugs, most applications don't run well
> when u open corrupted documents.
Then those applications are broken. Malformed user input should not be
able to cause a crash. Those who have written or work regularly with
network services have learned this lesson many, many times over.
--
wac