Back from Black Hat

After some very long days and nights, the IE delegation is back from Vegas. Some sessions I found especially interesting:

They did a great job of highlighting the challenges of reconciling ease of use and security.

Even more valuable than the briefings were the informal meetings with security researchers and other members of the incredibly diverse security community. I want to thank all of the folks that engaged us in discussions and were willing to share their thoughts on security and IE.

It’s encouraging to see that we are on the right track with our process for secure software development and in sync with the industry’s best practices. Many of the techniques discussed at Black Hat, such as threat modeling or fuzz-testing, have been part of our process for some time now. At the same time, we’re keenly aware that we can’t let up in our efforts at improving the security of our products, and making security an integral part of our development culture.

The buzz was of course all about Michael Lynn’s disclosure of a vulnerability in Cisco IOS. The way this issue was handled was ‘sub-optimal’, to say the least. To me, it confirms the importance of working closely with the security community – which is what Black Hat was all about.

- Patrick

Comments (27)

  1. Anonymous says:

    Did you meat any black hats?

  2. Xepol says:

    Following blackhats for security advice is a little like doing exit interview for foxes leaving hen houses.

    Well it is important to learn where and how you were breached, you should also be proactively trying to do it to yourself. MS would benefit greatly from hiring an in house team of people to hack MS’s own code, preferably on pre-release code. This way, you stand a chance of them catching the holes first.

    Mind you, the danger is that you do something like Cisco – find the holes in pre-existing products and then try to bury your research. Not a wise idea. Even if you WERE to succeed, chances are someone else will find it themselves.

    Security is fast becoming a full transparency required issue, and I doubt that anyone playing the role of whistle blower for serious security issues is going to get anything more than a token slap on the wrist from a court, and likely nothing at all if the company affected actively attempts to HIDE the facts.

    Things like cisco routers are too important to the basic infrastructure to let this happen.

    Hopefully, Microsoft, as it improves, learns the full lesson presented by the cisco fiasco.

    – Xepol

  3. Anonymous says:

    <<MS would benefit greatly from hiring an in house team of people to hack MS’s own code, preferably on pre-release code.>>

    What makes you think they don’t have several such teams?

  4. UnexpectedBill says:

    What are the URLs for above? (second reply posting)

    I get the feeling that they are not anything good, so I’m not about to use any of them.

  5. Anonymous says:

    Individuals get fame and/or fortune by disclosing vulnerabilities outside of what Microsoft is calling the "proper channels." One good way to combat this is to incentivize reporting by offering rewards (cash money) and recognition to folks who communicate such things directly to the vendors. It’s cheaper in the long run…

  6. Xepol says:

    Will wrote:

    >> What makes you think they don’t

    >> have several such teams?

    You gotta be kidding, right? If MS had this resource, they would not be in their current situtation. Perhaps MS has hired one or two recently, but they need to create an entire inhouse department dedicated to nothing else other than hacking their own code rather that leaving it up to independant researchers, as their current activities clearly point to.

    Yes, MS has been active lately in buying security companies, which are often involved with that kind of person, but its rare to actually have them in house.

    If MS had more people on their team that thought like hackers, there would be less buffer overflow exploits. When I first saw the C language, and its so called string handling, stack smashing was the VERY first thing that occured to me. I come from a pascal background, where strings are managed resources, so C’s lack of size management horrified me in its CLEAR implications. It is obscenely easy to see how easy it is to abuse C string management if the developer doesn’t actually make a deliberate effort.

    Yes, this is now addressed in C#, but MS’s dependance on stack checking does nothing to address the problem (and can be defeated, and even when not defeated can easily be turned into a denial of service attack instead). Clearly, the people at MS are NOT yet thinking like hackers, or being clearly advised by people who think like hackers.

    After all, the first thing a hacker would tell them is that strcpy and related un-limited string routines should be removed from their libraries entirely, and that string buffers on the stack should be dynamically allocated in heap instead. Hey, it’s just a pointer to C, it would be EASY to move it off the stack, but would require seperate allocation and deallocation occuring automatically every time the routine started up, causing a slight performance hit. I am amazed that after all this time, MS hasn’t made this an option in their C language. Could you imagine how much more secure their apps would become almost instantaneously?

    So no, I doubt that MS has hired a staff of hackers to crack their own code and advise them how to fix it. If they have, they’ve either not listening to them, or they hired the wrong hackers.

    – Xepol

  7. Anonymous says:

    Re: Xepol

    We haven’t used strcpy in a while. All the automated source checking finds those glaring errors.

    Moving stuff to the heap doesn’t solve anything, heap overflows are just as exploitable as buffer overflows. Yeah slight performance hit… Magic bullet… You can run that one by the perf team. 🙂 There’s no reason to side step an issue like that with a bandaid fix thats just as hackable.

    Not trying to say you aren’t leet as hell or something, but you are making assumptions about stuff that I know to be completely false. You think that no one at MSFT has ever hacked anything or been hacked. SSSSUURRREE. And for those who aren’t "leet hax0rs" already, Secure Code is now required reading as is a ton of security training.

  8. Anonymous says:

    I can not find where I can report IE7 beta1 possible bugs?

    So I post here:

    1) PNG file may not display, which was created via GDI+

    2) In hosted WebBrowser program, it throw exception IEFRAME.DLL 0xc0000005:Access Violation




    when call CWnd(derived)->DestroyWindow() in child thread(It was created in child thread as well).

    3)When I run my hosted WebBrowser in VC6 debug, in hotmail, when view a email Press Put in Folder and choose a folder, after refresh, the whole program lost focus(i.e. it shows light blue, inactive state), no other program get focus either, mouse click the window, it get active.

    my os XP sp2 Dell P4M 2.0G


  9. Anonymous says:

    Will wrote:

    >> What makes you think they don’t have several such teams?

    Xepol wrote:

    >> You gotta be kidding, right? If MS had this resource, they would not be in their current situtation. Perhaps MS has hired one or two recently

    Xepol, come now, the majority of Microsoft’s security updates and so forth comes on the heels of *Microsoft* security testing and research. Sure they could do more (and seem to be rapidly improving in this area), but they already have some of the industry’s best response time (in 99% of cases) to newly discovered vulnerabilities, especially given that their products probably get more attention from hackers (due to their market dominance) than any other company on the planet.

  10. Anonymous says:

    I suppose that all the viruses and spyware come from Microsoft’s own security testing and research too.

  11. Anonymous says:

    All three external URL links you provide are dead.

  12. Anonymous says:

    Well, to be fair, the vast majority of viruses and spyware use old vulnerabilities that had been patched by MS for months at least.

    (for example: Blaster).

    So in a sense, it really is the hackers who are playing catch-up to MS. The problem isn’t in MS not finding and plugging the holes, it’s the users failing to keep their machines uptodate.

    SP2 and its automatic updating by default should help alleviate that problem.

  13. Anonymous says:

    There’s no sign still of Microsoft learning the key lesson of OpenBSD. All undiscovered bugs and even many known bugs are security bugs, because bugs violate the expectations of the programmer, and once those expectations are violated all bets are off. That makes the opportunity cost of "new features" much higher than Microsoft allows for.

    As to design level security, Microsoft’s security on the wire is still terrible, they flood valuable information on broadcast; they practically encourage downgrade attacks with their approach to backwards compatibility; they use things like UTF-16 which are inherently more subject to misinterpretation attacks; etc.

    As to Microsoft being fast-to-fix, that’s a paper only result achieved by asking grey hats to stay silent while Microsoft fixes bugs (otherwise Microsoft threatens to cut off the oxygen of publicity, or even persue damages). If your threat model says "script kiddies might attack me at random" that’s better than nothing, otherwise it’s worse, much worse. So Microsoft gets good paper results and leaves the most exposed customers to take a bullet for them.

    FWIW The Cisco scenario is like this:

    The outcome of an attack splits three or four ways. You might get a DOS, either temporary or permanent, so that users and administrators are inconvenienced but nothing much happens. You might be able to get unprivileged code execution, or ability to influence the execution path of a single program, e.g. force a web browser to write a file somewhere. You might get full system level privileges, total control of the remote machine.

    Previously it was believed that the last option was impossible on Cisco’s major router platforms. So the worst a kiddy could do to your Cisco was DoS it or force it to reboot, or maybe tamper with/ temporarily disable some specific feature. The Cisco would still be yours, and when you fixed it, all was well.

    This was hugely better than Unix or NT systems, let alone an old-time OS like Mac System 7 or BeOS. On those systems you always have the potential, after an attack, that your system is compromised in an unidentified way. Maybe your website is back online, but now every new username & password is being secretly encoded into the ping responses of the machine. Or maybe there’s a "knock answering" port that opens a backdoor shell, if only you know the right TCP flags to set. So you either take risks, or every serious attack means a total rebuild & a "Sorry, your passwords may have been stolen" sign.

    The discovery presented at conference, and which will eventually leak out one way or another, was that it’s possible in practice to do this to a Cisco too, at least with some Cisco bugs. Obviously black hats and grey hats will now try to reproduce this, and future Cisco advisories may be more cautious. I have Cisco kit, but it’s replacing BSD machines, so we’re no more exposed because of this than we were before.

    If you had routers (Cisco or not), or worse, actual server OS boxes that you’d assumed were inviolable, this should be a wakeup call. If you can reprogram it over the network, there will be a way, somehow for a script kiddy to reprogram it too. Your threat assessment should consider this, even if it’s only to dismiss it as comparatively unlikely. Couldn’t that router have its management interfaces physically secured? Can the weekly "at risk" period include 5 minutes to reboot the core router with a new OS, rather than waiting for that weekend of downtime you’ve been promised since last October? Does the Big Boss really need a 3750G for his suite, when a much stupider and therefore less dangerous 24 port Netgear would do?

  14. Anonymous says:

    To Steve and others, you are joking right?

    eEye (just an example) pwns these guys (IE) on a regular basis, and they’re white hats.


    Of course, IEBlog don’t tell you about it because they’re more interesting in marketing than the safety of their users. M$ then sits on the bug reports for months and months.

    SP2 was a step in the right direction but to suggest its a panacea or even vaguely adequate is ridiculous. That said, Mozilla is even worse, they wouldn’t know what a code audit was if you smacked them in the face with it.

  15. Anonymous says:


    &lt;tvns:treenode NavigateUrl=’foo’&gt;

    So are ie treecontrols unsupported for IE7? Is this one of those backwards-compatability issues that will be dumped for the sake of progress?

    MSDN says this "Microsoft Internet Explorer WebControls are not currently supported." but said that during IE6 SP2 when they still worked.

    A heads-up either way would be good the sooner the better.


  16. Dave Massy says:


    Those web controls should still work in IE7 as they did in IE6. The statement is a little misleading in that those controls are built upon supported technology while the controls them selves are not directly supported. Since those controls are basically made up of HTML files all the necessary code is there for you to reuse and modify. I think it is a fairer description to call these samples that you are free to reuse and alter. I thought we had changed that categorisation some time ago but I’ll follow up and see if we can do so now.



  17. Anonymous says:

    URLs to presentation have been updated.

    David – thanks for pointing out that they had gone stale.

  18. Anonymous says:

    It was nice to see some of you at Ceasars. To bad I couldn’t talk to you all. But at least IE has a face for me now.

    Just the car/ped accident at the Strip 2 days before made me a little bit sad.

    PS: I know I mentioned it in another thread, but why doensn’t the beta of IE 7 support IDN-Domains yet :-(?

    Sincerely Jean Pascal

  19. Anonymous says:

    With regards to international domain names, one of the issues is that several languages (e.g. greek, russian) have letters that are "the same as" latin letters.

    So, something like http://www.сіtіbа might not be the URL you think it is (to the casual observer looking at it, its not possible to identify that some of the letters are not actually latin.

  20. Anonymous says:

    You are right but this can’t be the reason to ignore that there exist languages in the world that are together spoken a lot more than English but can’t be used in domain names…

    I guess it would be possible to find a way to make it safe although there are similar looking letters. E.g. there could be a small red exclamation mark or something else that shows up always when there is a domain that mixes two kinds of languages…

    Whatever. The DNS should no longer be only Latin. The world has more languages and culture to offer.

    Regards Jean

  21. Anonymous says:

    I really expected an official answer on this hot topic…

    If you don’t want to discuss it in public please mail me at: (My first name)

    Jean Pascal

Skip to main content