BreakingPoint LiveLook: Security Strikes & Patch Tuesday
Our BreakingPoint LiveLook on Monday garnered some interesting thoughts, one left in the comments section asked for a video of the security research team on Patch Tuesday. Instead of waiting till next Tuesday we grabbed the camera and Dennis asked Todd Manning to tell us what it is like on Patch Tuesday and dive into what he does to create the security strikes used in our network equipment testing solution. Enjoy...
Now be sure to vote on Todd's inquiry at the end of the video. Either comment directly on the video (press +) or in the comments section.
Posted by Kyle Flaherty (2008/08/08 10:00:00 GMT+0)
RE: Microsoft Patch Tuesday
Posted by
Dennis Cox
at
2008-08-08 05:29
We have been fairly lucky on Microsoft Patch Tuesday, to be honest. First, we have discovered our fair share of them and that of course means they come out way before patch Tuesday. Second, we all have a large number of friends in the security space and there is nothing harder to keep quiet then a good vulnerability. So the back channels generally help us get them a bit before patch Tuesday as well. Sometimes, however, we just have to work at it. We have a good size team, a good VM library and all the right tools. If we get a hint as to were the vulnerability is via the patch notes and we get the diffs it’s just a matter of time. Sometimes it’s an hour till we release a strike, sometimes it’s a full day or more.
blahblah.com
Posted by
doiexist@blahblah.com
at
2008-08-09 06:30
Dennis, i really appreciate the honest account here. Actually I expected my original comment to be blackened out. Anyways, I know you right set of people with right set of tools and skills, however MSPT diffing and reversing is more than figuring out what has changed. In my exp, figuring out what has changed is easier task than reaching that code path.
Re: More than just what changed...
Posted by
Todd Manning
at
2008-08-11 11:49
@DoIExist:
Definitely, you are correct. After thinking about what I said in the video (including using 'like' about one hundred times), I definitely left out the most interesting parts of MSFT Tuesday stuff - getting the bug to trigger!
I agree, finding the change that fixes the bug is really just a first step. Once you find that, for instance, a certain field is being used to control a memcpy or similar, the next step is finding how to get to that code. After that, figuring out what kind of vulnerability this is (e.g. if the buffer is allocated in the stack or in the heap, or if you're able to overwrite SEH handlers, etc) is the next step in trying to exploit the bug, once you've found how to get your data into the correct codepath.
Thanks for your comments. Sorry for being so inaccurate in my response, I'm not the best interviewee.
-t.
Definitely, you are correct. After thinking about what I said in the video (including using 'like' about one hundred times), I definitely left out the most interesting parts of MSFT Tuesday stuff - getting the bug to trigger!
I agree, finding the change that fixes the bug is really just a first step. Once you find that, for instance, a certain field is being used to control a memcpy or similar, the next step is finding how to get to that code. After that, figuring out what kind of vulnerability this is (e.g. if the buffer is allocated in the stack or in the heap, or if you're able to overwrite SEH handlers, etc) is the next step in trying to exploit the bug, once you've found how to get your data into the correct codepath.
Thanks for your comments. Sorry for being so inaccurate in my response, I'm not the best interviewee.
-t.
doiexist@blahblah.com