Heck, I can't even prove I'm not a brain in a jar, how could I possibly prove that Maynor had the exploit? Unless perhaps you're willing to accept some set of existing premises...
For example, do you believe the vulnerability in question existed, and someone found it?
All the things I have mentioned are evidence, a word which you seem to want to use here to mean "irrefutable proof". None of this is irrefutable proof, if you choose to allow for the ridiculous and unlikely circumstance where Maynor is perfectly capable of finding and exploiting the vuln, but instead chooses to lie about it, and not do the work until after Apple releases the patch. There is nothing that can be done now short of Apple admitting they lied to satisfy someone with such a narrow view.
I see. So you're the kind of guy who doesn't like to commit to the Sun coming up in the morning until tomorrow. Fair enough.
If I'm interpreting your standards correctly, the only trustable proof that you would accept would be Apple admitting that they lied. Good luck waiting for that.
No. I'm of the opinion that he exploited the third party card, but tried to play it up as though maybe he was exploiting the built in too, but had not actually done so and found it harder than he anticipated. Then he refused to make a proper statement and waited until Apple released a patch for the vulnerabilities they found in their audit.
First off, let's be clear about what the claim is, since you use the phrase "play it up." Maynor gave a demo to Krebs of him exploiting the built in wireless, and the next day Maynor claimed during his talk that he was showing a video of him exploiting a third-party drive, and said he had a similar vulnerability for the built-in wireless.
So there's no hinting or implying, he stated up front that he could get a shell by exploiting the build-in wireless drive.
He then looked at the patch to find the vulnerability and quickly coded a crash of that vulnerability, but not a proper exploit because either he did not have enough time or he did not find it as easy as he hoped.
So what causes you to think things happened this way? Not even Apple is trying to make this claim.
You appear to acknowledge that: -He can write OS X kernel exploits (works for the thrid-party driver, right?) -He can find wifi kernel driver vulnerabilities -He can find and exploit the vulnerability in question, he just didn't before Apple released their patch
Let me throw in a few more assertions, and you tell me if you disagree with any of them: -2/3 of the original Black Hat talk was about Maynor and Ellch's wifi fuzzing toolkit -They used said toolkit to find vulnerabilities in (at least) Windows and OS X third-party wifi drivers -Maynor owns a Macbook, and showed it in his video
So, to arrive at your conclusion, Maynor would have had to: -Not tried his fuzzing toolkit against the built-in wireless (too lazy? too secure?) -Instead plugged in a third-party NIC and did that one -Crafted a fake demo for Krebs' benefit -Lied or assumed that he could get a shell with the built-in wireless for his talk -Spent a fair bit of time reversing the Apple patch instead of using the toolkit he helped write to find the same bug OR -Just finally got around to trying his toolkit months after his original talk and faked demo -Didn't care about his already considerable reputation, figured what the hack, and made false claims (too lazy?)
And now there isn't any Maynor could produce that would satisfy you, right? And there's nothing Apple could do that would prove their side. So you have to pick which one to believe based on what is available.
The reason to believe him is simple; because he exploits this kind of thing all the time. I find the extraordinary claim to be Apple's, the company that has a stated policy that they will not acknowledge any vulnerabilities before a patch is available.
So, is it fair to summarize your position that you think he can successfully exploit the third-party card, but can neither find nor exploit the built-in wireless driver?
Ha. I found it. As expected, I was right, and you were wrong: no evidence was presented by Maynor.
In fact, there was. He kernel panic'd a Mac live over the air with everyone watching (sniffing.)
I gather from your response that you believe his unwillingness to give out a working exploit (probably still owned by SecureWorks) to everyone means that he can't produce such an exploit. Even though Maynor has been doing this kind of thing professionally for years at ISS. Even though Ellch showed the vulnerability they found on Windows in the same way. Even though Apple only patched after being in contact with Maynor on the topic. Even though HD Moore found similar problems by looking in the same areas that Maynor & Ellch indicated.
You'd rather believe that he reverse-engineered the patch that he was (at minimum) the impetus for. You'd rather believe he is capable of reverse engineering the kernel patch, but not writing the exploit in the first place.
And I can see from the fact that you weren't even aware of the recent presentation that you've not been following the case very well.
If your likeliness meter is that miscalibrated, then there would seem to be little point in my presenting you with additional evidence that you are missing. Apple's PR department will give you all the technical detail you want.
The point about the 3rd party NIC in Ou's most recent article is that Lynn latched onto that to try and deny that similar vulnerabilities were also claimed in Apple's drivers for the built-in wireless. I know when they claimed discovery, I was in the presentation where they did.
Um... why does Ou think those researchers should get credit for uncovering a vulnerability in Mac OS X that (Ou reminds us over and over again) they themselves claimed, from the beginning, that they did not uncover?
Where did Maynor and Ellch claim they did not discover the vulnerability?
If I decide against a candidate, I've arrived at saying nothing beyond "Thank you for your time, we've decided not to extend an offer." Anything else, and I've had people keep bugging me with things like they can change, or give them another chance, or would I...
That's no different than any other SSO design. Read the rest of the thread about that. That won't help unless the environment is already set up for that kind of authentication.
Under exactly the right circumstances (i.e. all of your userbase always logs into the domain before running the database client app in question), this pushes the authentication problem to exactly where he wants it. Unfortunately, the original poster hasn't given nearly enough information to tell if Kerberos/AD/any-other-SSO will help his situation.
But as you've indicated, for other situations this won't help.
People try to do this sort of thing all the time. It's not actually secure, of course, but it makes for some entertainment. If you want some to play with, Google "crackme."
I don't see how an SSL certificate is going to help here. Since he's talking about authenticating clients, it would be a client certificate, which would have to be embedded in the app, same as a static password.
You can't secure a client-side password without another password to protect it. Which is contrary to what you're trying to accomplish. If you could give a bit more detail about what you're trying to accomplish, we could probably better enumerate the trade-offs.
Slashdot Mirror
Assassination Politics I think he went to jail for it.
http://www.symantec.com/security_response/writeup.jsp?docid=2006-110217-1331-99
Now that you have been proven wrong, you may proceed to explain why that one doesn't count.
What kind of evidence do you have in mind?
Heck, I can't even prove I'm not a brain in a jar, how could I possibly prove that Maynor had the exploit? Unless perhaps you're willing to accept some set of existing premises...
For example, do you believe the vulnerability in question existed, and someone found it?
All the things I have mentioned are evidence, a word which you seem to want to use here to mean "irrefutable proof". None of this is irrefutable proof, if you choose to allow for the ridiculous and unlikely circumstance where Maynor is perfectly capable of finding and exploiting the vuln, but instead chooses to lie about it, and not do the work until after Apple releases the patch. There is nothing that can be done now short of Apple admitting they lied to satisfy someone with such a narrow view.
You've got it. But you've replied a dozen times with "not good enough".
I see. So you're the kind of guy who doesn't like to commit to the Sun coming up in the morning until tomorrow. Fair enough.
If I'm interpreting your standards correctly, the only trustable proof that you would accept would be Apple admitting that they lied. Good luck waiting for that.
So, fair to say that you're not interested in the most likely truth in the Myanor vs. Apple situation, you're just here for the debate?
Kinda looks to me like you have.
And how do you know he was the impetus for it? (Psssst: you don't.)
The internal audit came as a result of claims by a senior researcher at SecureWorks
impetus
No. I'm of the opinion that he exploited the third party card, but tried to play it up as though maybe he was exploiting the built in too, but had not actually done so and found it harder than he anticipated. Then he refused to make a proper statement and waited until Apple released a patch for the vulnerabilities they found in their audit.
First off, let's be clear about what the claim is, since you use the phrase "play it up." Maynor gave a demo to Krebs of him exploiting the built in wireless, and the next day Maynor claimed during his talk that he was showing a video of him exploiting a third-party drive, and said he had a similar vulnerability for the built-in wireless.
So there's no hinting or implying, he stated up front that he could get a shell by exploiting the build-in wireless drive.
He then looked at the patch to find the vulnerability and quickly coded a crash of that vulnerability, but not a proper exploit because either he did not have enough time or he did not find it as easy as he hoped.
So what causes you to think things happened this way? Not even Apple is trying to make this claim.
You appear to acknowledge that:
-He can write OS X kernel exploits (works for the thrid-party driver, right?)
-He can find wifi kernel driver vulnerabilities
-He can find and exploit the vulnerability in question, he just didn't before Apple released their patch
Let me throw in a few more assertions, and you tell me if you disagree with any of them:
-2/3 of the original Black Hat talk was about Maynor and Ellch's wifi fuzzing toolkit
-They used said toolkit to find vulnerabilities in (at least) Windows and OS X third-party wifi drivers
-Maynor owns a Macbook, and showed it in his video
So, to arrive at your conclusion, Maynor would have had to:
-Not tried his fuzzing toolkit against the built-in wireless (too lazy? too secure?)
-Instead plugged in a third-party NIC and did that one
-Crafted a fake demo for Krebs' benefit
-Lied or assumed that he could get a shell with the built-in wireless for his talk
-Spent a fair bit of time reversing the Apple patch instead of using the toolkit he helped write to find the same bug
OR
-Just finally got around to trying his toolkit months after his original talk and faked demo
-Didn't care about his already considerable reputation, figured what the hack, and made false claims (too lazy?)
Where did my logic go off-track?
And now there isn't any Maynor could produce that would satisfy you, right? And there's nothing Apple could do that would prove their side. So you have to pick which one to believe based on what is available.
The reason to believe him is simple; because he exploits this kind of thing all the time. I find the extraordinary claim to be Apple's, the company that has a stated policy that they will not acknowledge any vulnerabilities before a patch is available.
So, is it fair to summarize your position that you think he can successfully exploit the third-party card, but can neither find nor exploit the built-in wireless driver?
See also above.
Ha. I found it. As expected, I was right, and you were wrong: no evidence was presented by Maynor.
In fact, there was. He kernel panic'd a Mac live over the air with everyone watching (sniffing.)
I gather from your response that you believe his unwillingness to give out a working exploit (probably still owned by SecureWorks) to everyone means that he can't produce such an exploit. Even though Maynor has been doing this kind of thing professionally for years at ISS. Even though Ellch showed the vulnerability they found on Windows in the same way. Even though Apple only patched after being in contact with Maynor on the topic. Even though HD Moore found similar problems by looking in the same areas that Maynor & Ellch indicated.
You'd rather believe that he reverse-engineered the patch that he was (at minimum) the impetus for. You'd rather believe he is capable of reverse engineering the kernel patch, but not writing the exploit in the first place.
And I can see from the fact that you weren't even aware of the recent presentation that you've not been following the case very well.
If your likeliness meter is that miscalibrated, then there would seem to be little point in my presenting you with additional evidence that you are missing. Apple's PR department will give you all the technical detail you want.
Neither. They claimed it, and have evidence for it. Maynor finally presented some of the evidence recently at Black Hat Federal.
The point about the 3rd party NIC in Ou's most recent article is that Lynn latched onto that to try and deny that similar vulnerabilities were also claimed in Apple's drivers for the built-in wireless. I know when they claimed discovery, I was in the presentation where they did.
Um ... why does Ou think those researchers should get credit for uncovering a vulnerability in Mac OS X that (Ou reminds us over and over again) they themselves claimed, from the beginning, that they did not uncover?
Where did Maynor and Ellch claim they did not discover the vulnerability?
If I decide against a candidate, I've arrived at saying nothing beyond "Thank you for your time, we've decided not to extend an offer." Anything else, and I've had people keep bugging me with things like they can change, or give them another chance, or would I...
That's no different than any other SSO design. Read the rest of the thread about that. That won't help unless the environment is already set up for that kind of authentication.
Under exactly the right circumstances (i.e. all of your userbase always logs into the domain before running the database client app in question), this pushes the authentication problem to exactly where he wants it. Unfortunately, the original poster hasn't given nearly enough information to tell if Kerberos/AD/any-other-SSO will help his situation.
But as you've indicated, for other situations this won't help.
You don't think that's actually safe, do you? You've just made it more complicated (aka fun to crack.)
People try to do this sort of thing all the time. It's not actually secure, of course, but it makes for some entertainment. If you want some to play with, Google "crackme."
I don't see how an SSL certificate is going to help here. Since he's talking about authenticating clients, it would be a client certificate, which would have to be embedded in the app, same as a static password.
You can't secure a client-side password without another password to protect it. Which is contrary to what you're trying to accomplish. If you could give a bit more detail about what you're trying to accomplish, we could probably better enumerate the trade-offs.