"Most Developer Resources [on .NET] are Wrong"

[joohang]

Linkie

 

[Nothinman]

They're not really wrong, they're just poorly and insecurly done. I can't believe anyone would be surprised though, MS consistently releases software with the right target but with a really poor implementation or little/no security behind it.

 

[joohang]

<< They're not really wrong, they're just poorly and insecurly done. I can't believe anyone would be surprised though, MS consistently releases software with the right target but with a really poor implementation or little/no security behind it. >>


I agree with the argument against IBuySpy, but it's pretty dumb to attack MSDN documentation.

The whole point of documentation is to teach you how to write a specific aspect of code, not to teach you everything there is to know. Adding security code and taking every damn measure will only complicate the documentation. MSDN is not perfect but it shouldn't be criticized for simplified sample code, which improves clarity.

 

[Nothinman]

The whole point of documentation is to teach you how to write a specific aspect of code, not to teach you everything there is to know.

True, but they don't even make it a point to explain when something is dumb to do. For example, the strcpy page in the .NET docs makes no mention of bounds checking or strncpy.

 

[joohang]

<< The whole point of documentation is to teach you how to write a specific aspect of code, not to teach you everything there is to know.

True, but they don't even make it a point to explain when something is dumb to do. For example, the strcpy page in the .NET docs makes no mention of bounds checking or strncpy. >>


True, although I have no clue what strcpy does.

 

[Shazam]

If you're using toy examples as your basis to writing production code, I suggest you grab a brain.

I suppose this is a big problem these days. One of my Java books says that if you consider their toy examples as "real code", don't.

 

[manly]

I agree with Nothinman here, even though I'm not an MS developer.

In fact, in the linked article, even the .Net Framework PHB makes a positive statement that agrees with Nothinman. Very atypical of a PHB; he was probably an engineer in a previous life.

 

[Descartes]

<< For example, the strcpy page in the .NET docs makes no mention of bounds checking or strncpy. >>



Because bounds cheching is ancillary to the behavior and use of strcpy(). Are they going to regurgitate the same "check your bounds" mantra on all routines that are potentially able to wantonly overwrite EIP? What about format string vulnerabilities? Is it really MS' job to supply a caveat for all known issues associated with a given routine? One also has to note that strcpy() is ANSI, but do you find warnings of it's use in ANSI C89 or ANSI C99? Nope.



<< True, but they don't even make it a point to explain when something is dumb to do >>



So, you would also agree with that lawsuit that required McDonald's to include the "Warning: Hot Coffee" label on all obviously hot cups of coffee? Same issue, really. They supplied a consumer with something that could be potentially harmful if used improperly. I certainly wouldn't take a hot cup of coffee and pour it all over myself, nor would I copy/paste code from documentation and call it production code.

 

[Nothinman]

Because bounds cheching is ancillary to the behavior and use of strcpy(). Are they going to regurgitate the same "check your bounds" mantra on all routines that are potentially able to wantonly overwrite EIP?

Yes, I believe there should be a little blurb about "this is the function we always fsck up using that makes IIS so insecure, don't code like us!" =) You would think they would atleast plug their CString or sdt::string classes as a replacement for c-style char arrays.

Is it really MS' job to supply a caveat for all known issues associated with a given routine?

No, but it would be nice. Every man page I've read for strcpy says 'you should use strncpy instead, it's safer', it's not like it's a lot of work to type an extra sentence or two about security.

I , you would also agree with that lawsuit that required McDonald's to include the "Warning: Hot Coffee" label on all obviously hot cups of coffee

No, that's different. That woman has been drinking coffee for years and should have known better, not all programmers know all the caveats of all the functions they call.

 

[Mucman]

Intersesting! I think I may have my work cut out for me in the next few months My felt the pressure to put .NET on our web servers when neither of us knew a whole lot about the framework! Not something I like to do but he is the boss... Any of you got some tips on .NET administration? We are using the impersonations="true" attribute in the machine.config so that NTFS permissions prevent people from accessing other peoples home folder.

 

[Bluga]

<< If you're using toy examples as your basis to writing production code, I suggest you grab a brain. >>



so true.

 

[Nothinman]

<< If you're using toy examples as your basis to writing production code, I suggest you grab a brain. >>



so true.

How am I supposed to know that a function is potentially dangerous if the docs don't tell me?

 

[gopunk]

wouldn't strcpy be a string copying function? or maybe i'm thinking of something else...

 

[Nothinman]

Yes, it is.

 

[Descartes]

<< No, but it would be nice. Every man page I've read for strcpy says 'you should use strncpy instead, it's safer', it's not like it's a lot of work to type an extra sentence or two about security. >>



#man strcpy
...


<< BUGS
If the destination string of a strcpy() is not large enough (that is, if the programmer was stupid/lazy, and
failed to check the size before copying) then anything might happen. Overflowing fixed length strings is a
favourite cracker technique. >>



Doh, you're right. MS had this to say in the platform SDK...



<< No overflow checking is performed when strings are copied or appended. The behavior of strcpy is undefined if the source and destination strings overlap. >>



A little less explicit, as there wasn't the "stupid/lazy" programmer reference



<< No, that's different. That woman has been drinking coffee for years and should have known better, not all programmers know all the caveats of all the functions they call. >>



I agree, but there are many more dismal things one could do when working in a language like C.

 

[Nothinman]

A little less explicit, as there wasn't the "stupid/lazy" programmer reference

Just a little? It doesn't say at all how it can be dangerous, undefined could mean anything.

I agree, but there are many more dismal things one could do when working in a language like C.

I dunno, the IIS team seems to be able to accomplish some pretty dismal things with functions like strcpy.