#10 = #11 ??
dinornis
description for: a broken file can crash your computer. Bad Apple for
letting that happen, but, how in any natural course of events would a
.dmg end up with 537byte blocks?
LMH claims #10 leads to "potential arbitrary code execution." That's
not good enough where I come from. Either the arbitrary code executes,
or it doesn't. I may be talking thru my elbow, but I suggest the
absence of a working example of "arbitrary code execution" is that we
have caused a kernel panic, and stack based execution ceases.
#11 we are told is unlikely to be abused to cause arbitrary code
execution. We may never know, because the PoC he has posted is the
identical file for #10. It has been there for over 24 hours now, I
guess nobody complained ;-)
And to finally register my dismay at his standard of workmanship, the
MOAB-10-01-2007.dmg is just a spare piece of his hard disk, not even
cleaned or primed for this demo. Maybe the references to Daring
Phuxball were supposed to be in there, maybe not, I thought that was
leftover from the November jok^H^H^H kernel bugs. I know if I were
producing a 'sploit like this the image would be full of zeroes, or
perhaps full of magic numbers...
C'mon LMH, quit gnat farming, give us some real bugs.
Eric Hall
>
> I call Mr. LMH. I think he's scratching. What we have here is a fancy
> description for: a broken file can crash your computer. Bad Apple for
> letting that happen, but, how in any natural course of events would a
> .dmg end up with 537byte blocks?
You get one when somebody crafts it to exploit the vulnerability.
This is the class of bug that escapes the "classic" QA (QA to the spec,
and maybe a bit beyond) but doesn't escape the security researcher,
h4x0R, or an extremely robust QA system.
>
> LMH claims #10 leads to "potential arbitrary code execution." That's
> not good enough where I come from. Either the arbitrary code executes,
> or it doesn't. I may be talking thru my elbow, but I suggest the
> absence of a working example of "arbitrary code execution" is that we
> have caused a kernel panic, and stack based execution ceases.
>
[snip]
Finding bugs takes a certain amount of time (even just running
a fuzzer against something). Creating a PoC (usually) takes a lot
longer. That (to me at least) a PoC doesn't currently exist takes nothing
away from the potential.
My favorite reference in this area is the 1 byte overflow in
sudo (google around for 'vudo'). It wasn't thought to be exploitable,
then turned out it was. Look it up, there's some good info in the
various writeups.
With that in mind, I suggest you keep a more open mind to the
possibilities that while there is no *public* PoC, there may well
be multiple private implementations that exploit the vulnerability,
and do your risk assesments accordingly.
-eric
Rosyna
can confirm this by reading the log that is provided:
#0 Debugger (message=0x3c9540 "panic") at
/SourceCache/xnu/xnu-792.13.8/osfmk/i386/AT386/model_dep.c:770
#1 0x00128d1f in panic (str=0x3d100c "getbufzone: incorect size = %d") at
/SourceCache/xnu/xnu-792.13.8/osfmk/kern/debug.c:202
#2 0x001c0d97 in allocbuf (bp=0x25aa5180, size=-3072) at
/SourceCache/xnu/xnu-792.13.8/bsd/vfs/vfs_bio.c:2448
the panic() function takes a string for the reason the panic
occurred. As you can see from the above, the reason us due to the
fact the buffer size is absurd. The system caught this absurdity and
handled it by calling panic().
In other words, not capable of executing arbitrary code.
Ack, at 1/12/07, dinornis said:
>LMH claims #10 leads to "potential arbitrary code execution." That's
>not good enough where I come from. Either the arbitrary code executes,
>or it doesn't. I may be talking thru my elbow, but I suggest the
>absence of a working example of "arbitrary code execution" is that we
>have caused a kernel panic, and stack based execution ceases.
--
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.
st...@info-pull.com
On Jan 13, 4:59 am, "dinornis" <p.k...@auckland.ac.nz> wrote:
> LMH claims #10 leads to "potential arbitrary code execution." That's
> not good enough where I come from. Either the arbitrary code executes,
> or it doesn't. I may be talking thru my elbow, but I suggest the
> absence of a working example of "arbitrary code execution" is that we
> have caused a kernel panic, and stack based execution ceases.
Actually if you happened to barely understand or read the issue, the
buffer is allocated in heap space.
Not even commenting about the other non-sense ("caused a kernel
panic,stack based execution ceases" ...).
At kernel-land, the most common approach in a exploit is to modify a
task data structure for giving root privileges to the target process.
This has been documented by Ilja van Sprundel and Christian Klein in
2005:
http://www.blackhat.com/presentations/bh-europe-05/BH_EU_05-Klein_Sprundel.pdf
Anyway, for starting a decent flame war, you have to get right at least
some minimal points first.
Have a nice read.
st...@info-pull.com
On Jan 13, 6:49 am, Rosyna <ros...@gmail.com> wrote:
> It's not exploitable. The kernel catches it can causes a panic. You
> can confirm this by reading the log that is provided:
>
> #0 Debugger (message=0x3c9540 "panic") at
> /SourceCache/xnu/xnu-792.13.8/osfmk/i386/AT386/model_dep.c:770
> #1 0x00128d1f in panic (str=0x3d100c "getbufzone: incorect size = %d") at
> /SourceCache/xnu/xnu-792.13.8/osfmk/kern/debug.c:202
> #2 0x001c0d97 in allocbuf (bp=0x25aa5180, size=-3072) at
> /SourceCache/xnu/xnu-792.13.8/bsd/vfs/vfs_bio.c:2448
>
> the panic() function takes a string for the reason the panic
> occurred. As you can see from the above, the reason us due to the
> fact the buffer size is absurd. The system caught this absurdity and
> handled it by calling panic().
> In other words, not capable of executing arbitrary code.
You're yet another time wrong. Please scroll down the Terminal window
and check the frames below those ;-).
allocbuf() is receiving a negative size because of the integer overflow
problem, that it makes it wrap around.
For abusing it to cause arbitrary code execution, all you need is make
it wrap to a low value, and let the copy that happens afterwards
overflow the heap-allocated buffer.
It's striking the lack of care you display when talking about matters
that apparently escape your understanding. No offense meant, but
there's no need to be an expert for finding the integer overflow issue
and where that negative size is coming from.
Please read the issue again, it's fairly well described. Don't mind
about talking to you and showing it step-by-step.
Cheers.
Rosyna
isn't exploitable?
Ack, at 1/13/07, st...@info-pull.com said:
>On Jan 13, 6:49 am, Rosyna <ros...@gmail.com> wrote:
>> It's not exploitable. The kernel catches it can causes a panic. You
>> can confirm this by reading the log that is provided:
>>
>> #0 Debugger (message=0x3c9540 "panic") at
>> /SourceCache/xnu/xnu-792.13.8/osfmk/i386/AT386/model_dep.c:770
>> #1 0x00128d1f in panic (str=0x3d100c "getbufzone: incorect size = %d") at
>> /SourceCache/xnu/xnu-792.13.8/osfmk/kern/debug.c:202
>> #2 0x001c0d97 in allocbuf (bp=0x25aa5180, size=-3072) at
>> /SourceCache/xnu/xnu-792.13.8/bsd/vfs/vfs_bio.c:2448
>>
>> the panic() function takes a string for the reason the panic
>> occurred. As you can see from the above, the reason us due to the
>> fact the buffer size is absurd. The system caught this absurdity and
>> handled it by calling panic().
>> In other words, not capable of executing arbitrary code.
>
>You're yet another time wrong. Please scroll down the Terminal window
>and check the frames below those ;-).
>allocbuf() is receiving a negative size because of the integer overflow
>problem, that it makes it wrap around.
>
>For abusing it to cause arbitrary code execution, all you need is make
>it wrap to a low value, and let the copy that happens afterwards
>overflow the heap-allocated buffer.
--
st...@info-pull.com
On Jan 13, 5:51 am, Eric Hall <g...@ghosthound.net> wrote:
> On Fri, Jan 12, 2007 at 07:59:38PM -0800, dinornis wrote:
>
> > I call Mr. LMH. I think he's scratching. What we have here is a fancy
> > description for: a broken file can crash your computer. Bad Apple for
> > letting that happen, but, how in any natural course of events would a
> > .dmg end up with 537byte blocks? You get one when somebody crafts it to exploit the vulnerability.
> This is the class of bug that escapes the "classic" QA (QA to the spec,
> and maybe a bit beyond) but doesn't escape the security researcher,
> h4x0R, or an extremely robust QA system.
>
Ironically, the fs bugs have been found by auditing the source code,
but needed to write a targeted fuzzing library in Ruby to deal with the
DMG format and reproducing them.
The integer overflows are pretty much evident all over the place,
nothing needed besides "sophisticated static code analysis tools" (also
known as a grep and awk). :-)
>
> Finding bugs takes a certain amount of time (even just running
> a fuzzer against something). Creating a PoC (usually) takes a lot
> longer. That (to me at least) a PoC doesn't currently exist takes nothing
> away from the potential.
> My favorite reference in this area is the 1 byte overflow in
> sudo (google around for 'vudo'). It wasn't thought to be exploitable,
> then turned out it was. Look it up, there's some good info in the
> various writeups.
Infamous one byte overflows :-)
Ilja gave a talk at the CCC on unusual bugs, describing reference
counter overflows and other sweet issues.
The PDF is over here:
http://www.ruxcon.org.au/files/2006/unusual_bugs.pdf
The CCC talk page seems to be down right now.
> With that in mind, I suggest you keep a more open mind to the
> possibilities that while there is no *public* PoC, there may well
> be multiple private implementations that exploit the vulnerability,
> and do your risk assesments accordingly.
On the Finder memory corruption issue, it seems to be exploitable.
We've been contacted by a fellow regarding some details he had about
the issue since some time ago and apparently there's some stuff to work
around. We'll try to check it sometime later and show details. Running
on limited time, though. We can pass the details to some people that
might be interested on poking around the issue further.
Cheers.
st...@info-pull.com
On Jan 13, 7:18 am, Rosyna <ros...@gmail.com> wrote:
> So then, why didn't you show that instead of a case that clearly
> isn't exploitable?
You didn't even bother to debug it apparently. And again, please read
the issue. If you have trouble understanding it, don't hesitate to ask.
Quoting (http://projects.info-pull.com/moab/MOAB-10-01-2007.html):
"Arbitrary code execution is possible, as we control the size parameter
used for buffer allocation and data is being copied directly from the
stream in the DMG image. The size value wraps, leading to a heap-based
buffer overflow when more data is being copied into the buffer
(fs->fs_csp / space) than it's prepared to handle."
(gdb) list ffs_vfsops.c:645
640 fs = ump->um_fs;
641 fs->fs_ronly = ronly;
642 size = fs->fs_cssize;
----- !
643 blks = howmany(size, fs->fs_fsize);
644 if (fs->fs_contigsumsize > 0)
645 size += fs->fs_ncg * sizeof(int32_t);
----- !
646 size += fs->fs_ncg * sizeof(u_int8_t);
----- !
647 space = _MALLOC((u_long)size, M_UFSMNT, M_WAITOK);
648 fs->fs_csp = space;
649 for (i = 0; i < blks; i += fs->fs_frag) { ----
(gdb) list
650 size = fs->fs_bsize; ----
651 if (i + fs->fs_frag > blks)
652 size = (blks - i) * fs->fs_fsize; ----
653 if (error = (int)buf_bread(devvp,
(daddr64_t)((unsigned)
fsbtodb(fs, fs->fs_csaddr + i)),
654 size, cred, &bp)) {
655 _FREE(fs->fs_csp, M_UFSMNT);
656 goto out;
657 }
658 bcopy((char *)buf_dataptr(bp), space,
(u_int)size);
#3 0x001c1d85 in buf_getblk (vp=0x2ee3ad4, blkno=454033632,
size=-3072, slpflag=0, slptimeo=0, operation=1)
at
/SourceCache/xnu/xnu-792.13.8/bsd/vfs/vfs_bio.c:2254
#4 0x001c1fdc in bio_doread (vp=0x0, blkno=0, size=-3072,
cred=0x2b9b404,
async=0, queuetype=1) at
/SourceCache/xnu/xnu-792.13.8/bsd/vfs/vfs_bio.c:1466
#5 0x001c227b in buf_bread (vp=0x2ee3ad4, blkno=454033632, size=-3072,
cred=0x2b9b404, bpp=0x13ebba8c) at
/SourceCache/xnu/xnu-792.13.8/bsd/vfs/vfs_bio.c:1552
#6 0x002e19b6 in ffs_mountfs (devvp=0x2ee3ad4, mp=0x2ec3d00,
context=0x13ebbf40) at
/SourceCache/xnu/xnu-792.13.8/bsd/ufs/ffs/ffs_vfsops.c:645
(gdb) i locals
ump = (struct ufsmount *) 0x2e74404
bp = (struct buf *) 0x0
fs = (struct fs *) 0x29c66000
dev = 234881029
cgbp = (struct buf *) 0x13ebbaa8
cgp = (struct cg *) 0x2cd4004
space = (void *) 0x2e41004
error = 49167060
i = -1929379836
ronly = 1
size = 4294964224
lp = (int32_t *) 0x0
cred = (kauth_cred_t) 0x2b9b404
dbsize = 0
rev_endian = 1
context = (vfs_context_t) 0x2e41004
Pay attention to lines 652-640.
Until there's any evident effort at your side for understanding it
instead of being an annoying retard, we will happily ignore your
nonsense.
Cheers.
Rosyna
being exploitable instead of the case that clearly shows the system
is purposefully panicking?
Yes, there's a validation bug.in the ffs_mountfs() wrt data
validation. However, if you didn't notice, it doesn't crash in the
function. The data *is* validated in allocbug(), found absurd, and a
panic is induced.
it's much like how [NSTask setPipe:] will throw an -[NSCFDictionary
setObject:forKey:] exception if you pass it bad data. The bad data is
checked and found as bad at a lower level.
Ack, at 1/13/07, st...@info-pull.com said:
>On Jan 13, 7:18 am, Rosyna <ros...@gmail.com> wrote:
>> So then, why didn't you show that instead of a case that clearly
>> isn't exploitable?
>
>You didn't even bother to debug it apparently. And again, please read
>the issue. If you have trouble understanding it, don't hesitate to ask.
>
>Quoting (http://projects.info-pull.com/moab/MOAB-10-01-2007.html):
Toad
Now I don't have much of a clue as to what
you are all talking about(its currently beyond my understanding). BUT
REMEMBER we are ALL on the SAME SIDE.
I hate to be blunt and please don't take offense at this, but a bug is
a bug and it needs to be fixed reguarless.
So having said that, Lets get back to positive thinking and not
negative attacks on one another.
(I am not siding with either party, and I wasn't paid to say this)
Toad
st...@info-pull.com
On Jan 13, 7:51 am, Rosyna <ros...@gmail.com> wrote:
> You're avoiding the question. Why didn't you show that case of it
> being exploitable instead of the case that clearly shows the system
> is purposefully panicking?
We aren't avoiding anything, we already explained it...
The exploitable condition is clearly described. And the fact that it
panics on allocation of a negative size buffer shows nothing but the
fact that we can use the integer overflow for subverting the buffer
allocation and later copy of data.
Rosyna, not sure the audience you're trying to speak for, but there's
little chance for speculation and down playing on this one.
> Yes, there's a validation bug.in the ffs_mountfs() wrt data
> validation. However, if you didn't notice, it doesn't crash in the
> function. The data *is* validated in allocbug(), found absurd, and a
> panic is induced.
You still don't understand the whole thing. There's no "validation bug"
per se. It's a integer overflow, as simple as that. A negative value
will make allocbuf() complain. A low value won't. We can cause it wrap
to a low value, and the buffer allocated would receive more data than
it's actual size, thus overflowing it.
Please read the description of the problem and the debugging output.
Not only you are alienating yourself but also pretending to be right
when in reality your displaying an offensive lack of care about
yourself. Again, if you have trouble *understanding* the issue, make
targeted questions.
http://en.wikipedia.org/wiki/Integer_overflow
http://www.securityfocus.com/bid/17056
http://www.felinemenace.org/~nemo/
Few people are capable of getting over c without first going through a
and b, and you aren't part of that crowd, much like everyone else.
Thus, if you still don't get it, and don't try to put a minimal effort,
we can't do anything more for you. Your limitations aren't something we
can solve anytime soon.
Rosyna
else was the question. Don't change the subject, don't try to insult
people, don't try to use a red herring argument.
Just flat out say why you didn't show the exploitable case and
instead showed an example that is clearly not exploitable.
if you say it's just a matter of making it overflow to the correct
size, then why didn't you just show that instead of showing an
"absurd" value. it's really a simple question and if possible, a
simple manner of making it happen.
Ack, at 1/13/07, st...@info-pull.com said:
>On Jan 13, 7:51 am, Rosyna <ros...@gmail.com> wrote:
>> You're avoiding the question. Why didn't you show that case of it
>> being exploitable instead of the case that clearly shows the system
> > is purposefully panicking?
>We aren't avoiding anything, we already explained it...
st...@info-pull.com
> I hate to interupt, but I figure I better before all gets out of hand.
> Now I don't have much of a clue as to what
> you are all talking about(its currently beyond my understanding). BUT
> REMEMBER we are ALL on the SAME SIDE.
> I hate to be blunt and please don't take offense at this, but a bug is
> a bug and it needs to be fixed reguarless.
> So having said that, Lets get back to positive thinking and not
> negative attacks on one another.
The problem here is that we are unable to make Rosyna get the points
right, even after explaining the issue and repeating ourselves a dozen
times. It's hilarious because of how clear the vulnerable condition is.
Still, he/she doesn't bother to read and instead proceeds to attempt
down-playing of the issue. It's these people who really harm the users.
Rosyna down played the APE issue, which was their own mistake (placing
a binary executed with root privileges on a writable path...) and now
tries to get on business again.
Not only they represent a great risk but also are abusing the ignorance
of unsuspecting users for making them have a false belief about their
products quality. How do they couple with it and try to hide their own
issues? Of course trying to spread the idea that the MoAB is evil.
> (I am not siding with either party, and I wasn't paid to say this)
;-)
Have fun.
dinornis
On Jan 13, 8:36 pm, s...@info-pull.com wrote:
>
> Not only they represent a great risk but also are abusing the ignorance
> of unsuspecting users for making them have a false belief about their
> products quality. How do they couple with it and try to hide their own
> issues? Of course trying to spread the idea that the MoAB is evil.
>
OK, I started this, and it'sobvious from my post my programming skills
are minimal, I normally use the other side of my brain ;-)
I never said, and I don't believe MOAB is "evil".
I welcome the exposure of these bugs, it'll help us all fix them
before the really bad guys find them.
But I'm not so comfortable with the way some of these bugs
are being presented. Two cross platform bugs (#2, 6) that crash
a Mac as easy as any other box should be blamed on the
application vendors, not Apple.
For # 10 & 11 it is claimed that a bug at point A in the source
is exploitable, but the invalid input in the PoC appears to be
trapped at point B producing a nonexploitable panic. Now
if a benign PoC has been released simply for demonstration,
well thank you ;-) but as I said in the post at the top of this thread
we wouldn't know for #11 because PoC#10 had been re-released
named as #11. I see that #11 is now posted on the index page,
but it's link on
http://projects.info-pull.com/moab/MOAB-11-01-2007.html
is still misdirected. I run a little website myself, and I know
ya gotta be on top of all those internal and relative links...
>
> Have fun.
I will ;-)
Alastair
>
> The problem here is that we are unable to make Rosyna get the points
> right, even after explaining the issue and repeating ourselves a dozen
> times.
Actually Rosyna does have a good point. If you're claiming that the
vulnerability is related to wrapping to a low value, why did you not
publish it as such? The example you posted was wrapping to a negative
value, which is quite different as you yourself admit.
I can't actually see info-pull.com at present (looks like I can't
connect to the web server), and I haven't had the time to look at the
bug in depth based on what's written here either, so I'm not going to
comment on how serious or exploitable the issue is in practice. But I
am still curious to see if you have a good answer for Rosyna's
question. Currently it looks like you are trying to avoid giving one.
Regards,
Alastair.
VistaUser
from here I have seen several replies to Rosyna's questions... I would
personally be tired of trying to explain things.
(eaemtyx02)
Rosyna
They've so far been replies to questions I never asked.
--
antibozo
> But none of them have actually been a reply to my *one* question.
> They've so far been replies to questions I never asked.
Perhaps, but that one question is of no importance whatsoever, and you
could easily think of a variety of answers yourself. One might
conjecture, for example, that they hadn't worked out the tactic fully
at the time of publishing and figured it out later. Or maybe they were
hoping to achieve a re-compromise of one of the victims of the first
exploit using the new one, and therefore played down the severity. Or
maybe they simply wanted to lure someone into exactly this sort of
discussion--you yourself called them trolls two weeks ago. Pressing
them on this insignificant question is absurd; why would you assume
they would answer truthfully anyway?
The useful issues to discuss here are technical ones. Discussing
people's motivations isn't going to accomplish anything.