Safari vulnerability look before you leap

I’m sick and tired with people commentating on my work without either knowing the details or having enough technical expertise to perform a simple test and read the URL bar. Here’s an example, now I’ve tried to promote my work by submitting to the many media sources and highlight Apple’s poor security attitude but it appears that it’s not what you know but who you know in this society today and it’s a sad fact of life that skilled researchers often do not get a chance for their voice to be heard.

Windows screen shot:-
Safari screenshot

Screen shot on OS X:-
OS X screen shot

Update…

I’ve since spoken directly to Sunnet Beskerming and it appears to be a misunderstanding and they have since updated their site to confirm my exploit works on Safari beta. I’d like to offer my apologies for overreacting to their article and in future I shall contact people before posting a rant.

11 Responses to “Safari vulnerability look before you leap”

  1. kourge writes:

    Don’t worry, there are always readers reading your stuff, even if they don’t always comment.
    I mean, recently Apple’s attitude seems to be deemed as even worse than Microsoft.

  2. Gareth Heyes writes:

    Thanks kourge

    The sad thing is when Apple eventually get round to fixing this their PR machine will probably deny there was a problem and my research will look bogus like others are trying to do already.

  3. kost BebiX writes:

    I guess Apple wants to populate safari first, and then think about security πŸ™‚

  4. Sunnet Beskerming writes:

    Hi.

    Always nice to get slammed on an article.

    Perhaps you need to re-read the article and see that all we were highlighting was that there can be difficulty determining who is right when a researcher and company come to loggerheads over a claim (especially when the company responds publicly – as Apple did here).

    We do know that the exploit was targeted for the Beta version (and thus the iPhone), but it is also important to see whether it carried back to the OS X codebase (which it seemed that no one had mentioned).

    While Apple’s response was less than stellar, the rapid deterioration of your reasoned arguments does not help your position.

    Please read and comprehend more clearly before accusing us of impropriety :

    “Where there needs to be more awareness is with how applications should handle poor information being presented from a vector that is not considered a normal attack vector. In the case of the iPhone Safari bug, the argument being made was that it is still a serious problem when the local user opens and interacts with valid HTML / JavaScript content from the local filesystem – there could still be malicious content that passes data out to a remote system.”

    In no way does this contradict anything that you produced or provided.

  5. Gareth Heyes writes:

    To quote you:- “(for the record, the linked iPhone Safari exploit doesn’t seem to work on OS X).”

    Hmmmmm it’s statements like this that annoy me, you imply my days of research are bogus. I feel I’m justified. I think you’ve read the discussion on slackers and presumed that the exploit was local and have not read all the discussion were I demonstrate that it is possible to call remotely. Then you’ve no doubt tried it on Safari 2.04 and presumed my exploit doesn’t work.

    I will not change my outspoken nature, if I feel people are implying my research is invalid. Which clearly your quote demonstrates.

  6. Sam Clark writes:

    Gareth, you do some amazing work and I am an avid reader of this journal… But, you don’t half loose it when people don’t pay attention to you. Now, I totally understand how frustrating it is not to be listened to, especially when you know you’re right. But this flaming (and retention to be fair to you) of parties not listening to your advice doesn’t help your cause, it just gives the impression of a disgruntled child who should be ignored.

    Apple in particular are notoriously bad at dealing with security problems. They seem to take Steve Jobs attitude that third parties pointing out defects with their products should be ignored until they fix the defect themselves, then claim they fixed it all on their own – unfortunately, in-spite of this I still buy their products.

    Frustrating yes, annoying when they look right through you… probably most definitely. But just be happy in the knowledge that you’re right and they’re wrong. If it’s on here, people are seeing it and will mention it.

    Please don’t take this comment the wrong way, as I said at the beginning I think your work is essential to web security. Please keep up the good work.

    Now, feel free to flame away πŸ˜‰

  7. Gareth Heyes writes:

    Thanks for the kind words Sam, yeah I do tend to overreact because of frustration and you’re right I need to stop with these knee jerk reactions. I guess that’s just my personality and I can’t help defending myself when I think someone is in the wrong.

    In future I’ll think before I post πŸ™‚

    I’ll save you from the flames πŸ˜‰

  8. Tom Macklin writes:

    I have a lot of respect for you Gareth because you stick with it. I used to be pretty much a full-time penetration tester, but between making enemies in the developer community and being ignored by my customers I could not take it anymore and went back to being a plain-ole’ developer. To be honest, I am not sure which bothered me more; I think it was being ignored b/c folks payed me good money and then didn’t do anything with the results!

    On a different note, do you think any major corporate software vendors *are* committed to building secure applications?

  9. Gareth Heyes writes:

    Thanks Tom

    I’m not bothered about making enemies in the developer community and people often mistake me for having a go at them, I simply love finding security holes in things and that’s what I really enjoy.

    I can deal with being ignored and I’ll stick to technical posts from now on and stop these childish but funny arguments.

    Software vendors are interested in profit and security does not come into the equation for that reason. It is easier for a vendor to release insecure code than account for more time programming and testing. Security offers the vendor nothing in terms of a visible difference between something that is secure and something that is not.

    It’s possible to change quite easily by:-
    1. Offering companies incentives for writing secure applications. e.g. Good publicity for no security holes.
    2. Educate programmers to code correctly and be aware of flaws in frameworks and programming languages.
    3. Employ management staff which aware of secure practices and enforce penalties for programmers which don’t conform to secure code.

  10. Tom Macklin writes:

    I think #1 is the most challenging, since most companies can claim something like, “well nobody is totally secure, but we are the most secure, so aren’t we great” basically for free. It’s probably a dream, but I would like to see the software community shun claims of security of the form “we’re secure because people haven’t found problems yet” in favor of arguments of the form “we’re secure, and here’s the evidence.”

    The common criteria process is supposed to enable this, but IMHO it’s mostly broken.

  11. Online backup writes:

    this very nice, thank you.