Michael Howard - How hackers operate

The Discussion

• 

  I always wanted to see more of Michael Howard videos amoung many others. I sometimes wonder if these Channel 9 guys are reading my mind, or something.
  
  Isn't that Brad Abrams in the grey t-shirt, occupying the corner seat right behind Michael Howard?
  

• 

  Please tell me more.  I want to know how to write secure code.   I love this series of video.
  

• 

  Michael Howard's videos are great. Is there any chance of getting this video in a downloadable form?
  
  Thanks,
  Colin.

• 

  Unfortunately I don't have this one in downloadable form. Sorry.

• 

  Just out of curiosity, what determines weather a video can be downloaded or not?
  
  Cool video. I havent read "Writing Secure Code" yet but, this video makes me want to go grab a copy and definately work harder to keep the "sKrypt Kddyz" away from my work.
  
  -Brian

• 

  brian8480 wrote:

  Just out of curiosity, what determines weather a video can be downloaded or not?
  
  Cool video. I havent read "Writing Secure Code" yet but, this video makes me want to go grab a copy and definately work harder to keep the "sKrypt Kddyz" away from my work.
  
  -Brian

  
  
  Heh, I have this book but can barely understand a good 60% of it due to my level of programming comprehension.
  
  
  
  
  mVPstar

• 

  Michael Howard's gives the power to think  about sec in real time .
  
  Arun
  

• 

  Beer28 wrote:

  basically, I'm trying to say that no one is going to use unchecked socket data as a malloc length or a memcpy length.
  
  If they do, their app should not be used. And that's the importance of open source. 
  

  
  
  And yet there are thousands of instances of it, sure in simple cases it's easy to spot but in others it's easy to miss. Buffer overflows are the #1 cause of security flaws in any operating system.
  
  Open source is not a silver bullet to protecting against such exploits. Neither is managed code, although it is considerably better in this regard.
  

• 

  I've learned through bitter experience to code as if I was under siege.  At every line of code, I ask myself... "What could go wrong here?  What assumptions am I making, and what happens if that assumption is wrong?"
  
  90% of the time the answer is "the function will fail in some appropriate fashion."
  
  10% of the time the answer is "the function will fail in this horribly dangerous or overdramatic fashion".  For example, a thread might, instead of sensibly dying with an error code, sit forever on an exclusive lock and tie up the rest of the application.
  
  That 10% of the time is what allows hackers in.
  
  Every function should consider its input to be malicious, and take steps to fail intelligently if it is.
  
  It's odd that he mentioned Perl in the context of a hacker tool, because Perl offers one of the few truly useful features for data sanitation - "taint" mode.  This makes it very useful for easily writing secure daemon software.
  

• 

  Beer28 wrote:

  
  How are you going to determine that an application you may be using has a buffer exploit if you can never see the source?
  

  
  
  Tick the DEP box and wait for Windows to pop up a dialog when a stack overrun occurs.
  
  

  Beer28 wrote:

  
  closed source makes them feel better about security
  

  
  
  Except that you just said open source makes you feel better about security, so you don't bother checking why you need so many updates?
  
  There are no silver bullets.