Writing Secure Code...

Hi, Everyone... 

Happy New Year! I've been lurking for awhile... time to "decloak" in '05. 

Item: The "ongoing" debate among choices of open source vs. proprietary (all
companies') solutions, not just the major players in the industry. 

I'm certain you've seen similar situations... where there are groups of 
people who are very opinionated one way or the other. My concern is the best
solution(s) security-wise, regardless of the source. Any comments? 
From a broad-brush perspective? 

Thanks! 

:: Cheri Sigmon | IT Specialist :: 
:: Hampton Roads, Virginia  USA :: 

-----Original Message----- 
From: David LeBlanc 
To: Alan Krassowski; Cc: Michael Howard 

Subject: RE: Microsoft Writing Secure Code 

Re-sending as plain text... 

I'll admit to spreading propaganda for the cause of getting developers 
to write secure code. I take extreme exception to any charge of the 
book's being an extension of our marketing department. They siezed on it 
AFTER we wrote it <g>. No one except ourselves had any say in what 
content we could put in the book, and to be honest, a lot of the content 
is showing people how Microsoft made mistakes that led to security 
bulletins (though we do pull out some other examples, like the old NFS 
remote root bug due to an integer overflow). 
  
Some of the book is Windows-centric - and some parts more so than 
others. I got my start in commercial programming by porting a large UNIX 
app to Windows NT, and though I haven't written much code on UNIX 
systems, I've written quite a lot that is portable and does run 
correctly on a range of OS's. Obviously not much lately. Where possible, 
I did try to consider cross-platform issues, but I'm no expert in say 
the correct ways to use suid (of which there's about 3 different 
behaviors, all with their own gotchas). 
  
Even some of the stuff that is very Windows-centric, like the chapters 
on access controls (Chapters 6 and 7) still applies to anyone - 
operating systems do the same sorts of things and it's seldom that there 
are mistakes you can make on one OS that don't have analogues on other 
OS's. 
  
As someone else mentioned, if you're dealing primarily with UNIX/Linux 
systems, Viega and McGraw will have better coverage, though I contend 
that WSC2 will still be useful. 
  
I don't know what the deal is with the examples not being in synch. 
Michael and I ought to follow up on that and see. I know I still have 
mine in original form on my home system. 
  
WRT creating hard links, you do need some level of permissions to the 
file being linked to - not much, but you can't make a link to something 
you have no access to. The typical case on a modern Windows system is 
that you ought to be using the per-user %tmp% directory, and the attacks 
are solved much more robustly that way. Your argument that CREATE_NEW is 
a better approach is a good one - if/when we update the book, we'll have 
to take a look at that section. 
  
One section that is a bit outdated is the .NET Framework chapter. If 
you're dealing with .NET code, ".NET Framework Security" by LaMacchia, 
et. al. is a better reference, though to be fair, I think we spent maybe 
30 pages on it, and they have 800 AND are some of the people responsible 
for designing .NET's security. 
  
If you want something that's highly specific and to the point, Michael 
and I are working on another book with John Viega and David Wheeler - it 
ought to be on the shelves in about 6 months or so. We specifically 
chose this set of authors so that we'd have really good cross-platform 
coverage. 
  
At some point, Michael and I may update WSC2, and I'd certainly welcome 
feedback on either errata or areas you'd like to see more coverage. 
  
Lastly, thanks very much for the kind comments - we worked very hard, 
and it's good to know that it is helpful. 

________________________________ 

From: Alan Krassowski [mailto:[email protected]] 
Sent: Thursday, December 09, 2004 12:39 PM 
To: [email protected] 
Cc: Michael Howard; David LeBlanc 
Subject: RE: Microsoft Writing Secure Code 




In the simpler dictionary definitions of propaganda, "information that 
is spread for the purpose of promoting some cause" or "material 
disseminated by the advocates or opponents of a doctrine or cause", of 
course this book fits (as do most).  But, this is a semantically charged 
word with other connotations, so I can see why Michael would deny it. 
(Sophisticated propaganda always denies that it is so. ;-)  But, I agree 
it gives a reasonably balanced view and exposes Microsoft some security 
history "warts and all." 

Overall, the book is a tremendous resource.  The original poster can of 
course read comments to that effect on amazon or mspress site.   

But, for the more picky among us, there's a few items that appear to 
need some improvement.  I don't like how the companion examples haven't 
kept up with the 2nd edition of the book.  For example, the 
CleanCanon.cpp example softcopy installed via secureco2.exe off mspress 
matches the 1st edition of the book, but not the second much-improved 
version in the book. 

Another example: in the 2nd edition of the book, on p. 684, the 
CREATE_ALWAYS flag is advocated as best to use when creating a temp 
file, and assumes in a race condition attack that the attacker's file 
(well, its contents) will be destroyed.  But, if the attacker created a 
hard link to some other important file as part of his race condition 
attack, your app could end up destroying the contents of some important 
file, especially if your app runs with higher privileges than the 
attacker.  Seems to me that using the CREATE_NEW flag instead, checking 
the return value to see if you did indeed create the temp file and 
looping until you are successful (or jumping out to error handling when 
you determine that you are being race condition attacked successfully n 
times in a row!) would be better advice.  [Credit Pascal Meunier for 
pointing this out to me.] 

If it were more clear where updates of the book's contents and companion 
material were to be kept and where they should be reported, it might 
improve the book's value to the security community at large - doubt this 
thread is the best place to do it, but seems like many in this audience 
would be interested in this.  Errata for the 1st edition of the book is 
on mspress, 
http://support.microsoft.com/default.aspx?scid=kb;en-us;833560 and for 
the second edition appears to be kept on Michael's blog 
http://blogs.msdn.com/michael_howard/archive/2004/10/25/247417.aspx. 

-Alan 





"Michael Howard" <[email protected]> 

12/09/2004 01:17 PM 

        
To 
        <[email protected]>, "Rui Covelo" <[email protected]> 
Subject 
        RE: Microsoft Writing Secure Code       

There is certainly no "propaganda" in the book. David and I were given 
freedom to say what we wanted, and we did, there are lots of Microsoft 
vuln examples and internal Microsoft stories. 

[Writing Secure Code] http://www.microsoft.com/mspress/books/5957.asp 
[Protect Your PC] http://www.microsoft.com/protect 
[Blog] http://blogs.msdn.com/michael_howard 

[On-line Security Training] 
http://mste/training/offerings.asp?TrainingID=53074 



-----Original Message----- 
From: [email protected] [mailto:[email protected]] 
Sent: Thursday, December 09, 2004 7:38 AM 
To: Rui Covelo 
Cc: [email protected] 
Subject: Re: Microsoft Writing Secure Code 

On Thu, 09 Dec 2004 09:57:53 GMT, Rui Covelo said: 

> I was looking for some opinions about the book "Writing Secure Code" 
> from Microsoft press. The book is already "old" but I only got to read 
> it now... 

There's a Second Edition out, not sure if you knew that.  The 2nd Ed has 
been out a while, but is certainly not "old" in the sense of "info gone 
stale" - a quick check doesn't find anything outdated in it.... 

> I was wondering if any of you have read it and what you think about 
> it. Do you find it useful or plain microsoft propaganda (like I read 
> somewhere else)? 

There's a lot of Microsoft-specific info in there, but hardly 
"propaganda". 

It's definitely a useful book for the nuts-and-bolts info that the guys 
actually writing the code - it's a bit weak on the top-level design 
issues, 
but given the title, I can hardly fault them for that (it *is* a 
"writing code" 
book ;)