lazy coding standards turning away classic functions?

This is a discussion on lazy coding standards turning away classic functions? within the General Discussions forums, part of the Community Boards category; Originally Posted by happyclown Humans are the weakest link in security, so why not provide safer tools to reduce/negate the ...

  1. #16
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,189
    Quote Originally Posted by happyclown View Post
    Humans are the weakest link in security, so why not provide safer tools to reduce/negate the human factor?
    Right, we should also make scalpel's safer so that people who are clumsy can be brain surgeons.
    Until you can build a working general purpose reprogrammable computer out of basic components from radio shack, you are not fit to call yourself a programmer in my presence. This is cwhizard, signing off.

  2. #17
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,438
    Quote Originally Posted by EVOEx View Post
    Now for the 1st reason: just check the buffers. Check the input. Check for NULL variables. Sorry, but with a few more if's, most vulnerabilities can be avoided. All vulnerabilities like these I've seen (And I've seen a LOT) are because coders are trying to be more clever than they really are or simply use functions they don't know how to use.
    Now the 2nd reason: these are a bit harder, where both programmers assume the other person would check for something but neither of them does. That's why there needs to be good communication. If there isn't, one of the programmers screwed up. If there is, then one of the programmer used a function he doesn't know how to use (see 1).
    Everyone knows how to avoid buffer overruns, thank you. That doesn't mean buffer overruns didn't plague the Windows environment for over 2 decades on software... *cough*... built in well developed countries by expert software developers working for specialized companies while adopting strict development methodologies.

    So let's cut to the chase and openly admit that this has nothing to do with how much one knows or how well they are organized. Bugs are bugs, are bugs.

    Irregardless of the possibility of a piece of complex software to come out of a software house with 0 errors -- which I could believe in if these weren't only lone needles in the haystack of undefined behavior -- what is being presented here is not yet another educative measure, another book, another blog on Yet Again How To Avoid Buffer Overruns. And definitely this isn't about how ignorant we are for missing a buffer overrun. (Definitely better than being such because I happen to think I will never miss a buffer overrun).

    This is just an only an offered partial solution to the problem. Take it or leave it.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  3. #18
    Registered User
    Join Date
    Oct 2008
    Posts
    1,262
    That's because M$ has so many coders, and not all of them are competent.

    Competent coders can manage to avoid flaws. Really, how many buffer overflows have there been in apache's core? I don't believe there have been any.
    Let's face it, using some easy techniques, security flaws can be avoided by any sane programmer. It's just that coders are either stupid or lazy.

    I'm not talking about bugs. They can happen. I'm talking about exploitable vulnerabilities. They shouldn't happen.

    Finally, there was even an OS on slashdot a few days ago that was proven correct. If this proof is actually right, then that means: no security flaws. So I guess someone did it...

  4. #19
    {Jaxom,Imriel,Liam}'s Dad Kennedy's Avatar
    Join Date
    Aug 2006
    Location
    Alabama
    Posts
    1,065
    Quote Originally Posted by man memcpy
    MEMCPY(3) Linux Programmer's Manual MEMCPY(3)

    NAME
    memcpy - copy memory area

    SYNOPSIS
    #include <string.h>

    void *memcpy(void *dest, const void *src, size_t n);

    DESCRIPTION
    The memcpy() function copies n bytes from memory area src to memory area dest. The memory areas should not overlap. Use memmove(3)
    if the memory areas do overlap.

    RETURN VALUE
    The memcpy() function returns a pointer to dest.

    CONFORMING TO
    SVr4, 4.3BSD, C89, C99, POSIX.1-2001.

    SEE ALSO
    bcopy(3), memccpy(3), memmove(3), mempcpy(3), strcpy(3), strncpy(3), wmemcpy(3)

    COLOPHON
    This page is part of release 3.15 of the Linux man-pages project. A description of the project, and information about reporting
    bugs, can be found at Linux man-pages home.

    1993-04-10 MEMCPY(3)
    lines 1-32/32 (END)
    So, are we to assume that a programmer that is too stupid to check that the length will fit into the array would not be too stupid to put the correct length of the array into yet another parameter?

    I don't get it.

  5. #20
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,636
    Quote Originally Posted by EVOEx
    If I code alone, I claim to be able to do anything without any vulnerabilities in it. Sure, it takes a few looks at the manual once in a while to be sure that the string is always 0-terminated or similar.
    If you code alone without any code review, I think that it is quite likely that any non-trivial program that you write will have a security vulnerability somewhere.

    Quote Originally Posted by EVOEx
    Let's face it, using some easy techniques, security flaws can be avoided by any sane programmer. It's just that coders are either stupid or lazy.
    I would not be so harsh when talking about security flaws in general. For example, your advice to "check the buffers. Check the input. Check for NULL variables" can help to avoid buffer overflows and incomplete mediation, but are useless against time of check, time of use errors due to race conditions that may be difficult to detect.

    Quote Originally Posted by EVOEx
    I'm not talking about bugs. They can happen. I'm talking about exploitable vulnerabilities. They shouldn't happen.
    Security vulnerabilities are bugs that should not happen.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  6. #21
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,239
    Quote Originally Posted by happyclown View Post
    Removing and replacing unsafe functions, to improve security. A step in the right direction.
    The _s functions make nothing safer. All these functions do is add a parameter where the caller must specify the destination buffer size. Nothing prevents you from passing the wrong value there. Unfortunately, people seem to believe that by using these functions they are making themselves immune to buffer overflow.

    In my opinion the situation is worse than before, because now people think they can be lazy because they're using "safe" functions.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  7. #22
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by laserlight View Post
    If you code alone without any code review, I think that it is quite likely that any non-trivial program that you write will have a security vulnerability somewhere.
    Isn't that a highly theoretical instance? Generally, significant vulnerabilities are ones that exist in widely distributed stuff that is not developed by one person -- or, at least, there should be ample opportunities for others to consider looking for vulnerabilities in it. After all, for a vulnerability to be be vulnerable, it must be found by someone with some knowledge and skills.

    Again, it seems to me there are two significant factors here:
    1. the insecurites inherent to the windows operating system, which MS cannot go back in time and start again, so they are stuck with it
    2. malicous programmers (who may even work for MS) who will intentionally include an exploit and then covertly publicize it

    The second one may seem "crazy" or "paranoid" but I believe it -- the only truly bizarre element is a motive, but IMO there is no point in analysing human behavior as if it could be rationalized, etc. Obviously, people write viruses; why? Those people are as likely to be MS employees as anything else. It probably counts as easy pickins'.

    Quote Originally Posted by abachler View Post
    Right, we should also make scalpel's safer so that people who are clumsy can be brain surgeons.
    well who can't agree with that! But going with my assertion in #2, maybe when you lie down on the table you will want more than a friendly smile to reassure you that your medical practitioner isn't, occasionally, a psychopath in some subtle way, or at least that there are some regulations, etc, in place to discourage such behaviour.

    Considering that the risk of injury from bad software is slim to none, I imagine the temptation is much greater. My point is this is almost certainly to deal with intentional exploitation, not mistakes, so there is no point discussing it as if it were just about "being clumsy" or not. Of course, there is no way that MS can present it that way, that would be just disastrous PR and probably hurt moral for "the coach"
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  8. #23
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,438
    Quote Originally Posted by Kennedy View Post
    So, are we to assume that a programmer that is too stupid to check that the length will fit into the array would not be too stupid to put the correct length of the array into yet another parameter?
    Microsoft advertises a considerable reduction in disclosed vulnerabilities after the application of the SDL (which does include a vast number of other replacements that go also into many of its own API functions).

    Personally I find these numbers... debatable
    The truth is that this offers no possibility of static checking as you well point out. However, I believe that by forcing the inclusion of the target buffer size it at least moves the brain to focus on the size of both buffers and thus can help eliminate errors(*). By improving function signature(s) we know that, for instance, we can help guide towards a more correct usage of libraries we design. This is, at least a conscious design decision we are confronted sometimes. Or so I hear.

    It's of no use to argue against the immaturity of coders falling prey to buffer overruns. The fact is that after many years of being given free reign, we haven't proved ourselves worthy. On the other hand the SDL is really not about the programmers. It is about the users of the applications we develop. They are the victims of our decisions (or lack thereof) and obviously throughout the years we didn't give a damn on how damaging our ego can be to the stability and security of their systems.

    (*) It's possible that may also help more rapidly locate buffer overruns being originated by these functions.

    EDIT: Feel I need to clarify something concerning the second paragraph of this post. I'd like to point out that the SDL Process Template sets in motion an application development lifecycle that indeed allows for static analysis during implementation and other methodologies during the Design and Verification phases that apparently take great advantage of these function replacements. Alone, these functions do little more than force the programmer to give it some thought. There's no other apparent advantage. It's probably possible to argue they may even add to the problem since they may give a false sense of security. But they are first and foremost a part of the SDL, where their context becomes a lot more obvious.
    Last edited by Mario F.; 09-09-2009 at 02:08 PM.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  9. #24
    Registered User
    Join Date
    Dec 2006
    Location
    Canada
    Posts
    3,182
    If Microsoft's intentions are as innocent as they claim to be (all about security), they should make it clear, in the warning the compiler generates when you use an "unsafe" function, that the suggested replacement is non-standard and will only work for their compiler.

    Admittedly, GCC is also not doing so well here, either. It only points out uses of GNU extensions if you pass the "-ansi" flag (it checks for standard conformity), but at least it won't suggest the programmer to ditch a standard function for a non-standard one and sound like the non-standard one is in all ways better than the standard function (including standard conformity). Is there a "standard compliant" option in VS?

  10. #25
    In my head happyclown's Avatar
    Join Date
    Dec 2008
    Location
    In my head
    Posts
    391
    I will make a bold prection:

    M$ deprectes unsafe code, GCC follows 6-12 months later, changes are incorporated into the next C standard revision.

    You heard it here first.

  11. #26
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,189
    I love deprecated functions, thats just another way of saying its stable and wont get broken by a future release.
    Until you can build a working general purpose reprogrammable computer out of basic components from radio shack, you are not fit to call yourself a programmer in my presence. This is cwhizard, signing off.

  12. #27
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,239
    Quote Originally Posted by happyclown View Post
    I will make a bold prection:

    M$ deprectes unsafe code, GCC follows 6-12 months later, changes are incorporated into the next C standard revision.

    You heard it here first.
    If you think the gcc people will ever accept the idea that memcpy() should be deprecated then you are smoking the serious voo-dang.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  13. #28
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,438
    Agreed.

    There's nothing deprecated about these functions. The Microsoft wording is particularly pernicious, as if the C++ programming language existed only to serve the Microsoft Windows operating system. This is my one and only beef with the whole affair.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  14. #29
    Registered User
    Join Date
    Dec 2006
    Location
    Canada
    Posts
    3,182
    Quote Originally Posted by happyclown View Post
    I will make a bold prection:

    M$ deprectes unsafe code, GCC follows 6-12 months later, changes are incorporated into the next C standard revision.

    You heard it here first.
    I will make another bold prediction:

    You don't know what you are talking about. Your statement is as hilarious as me saying M$ will open source Windows soon because they will realize it's a better software model.

    Fanboy-ism like this is very dangerous. The computing world is much more than just Microsoft. You are being blinded by all your Microsoft love. Loving Microsoft is okay, of course, but try to go without Microsoft for a few months - Linux, OpenOffice, Firefox, GCC, open standards... You don't have to like it, but IMHO you should try it. Even if you end up still loving Microsoft, you won't be taking everything they say as the golden un-biased truth, and you will see many more faces to issues like the one at hand, and be able to stay neutral and objective.

    BTW, yes, I am biased towards Linux/GCC/open source stuff, but I have tried Windows extensively also, for many years. Can you say the same?

  15. #30
    'Allo, 'Allo, Allo
    Join Date
    Apr 2008
    Posts
    611
    Except that he's probably right, except it won't be until 201x. It seems one way or another the next C standard will have at least some "safer" replacements. (TR 24731).

    Quote Originally Posted by Mario F.
    Microsoft advertises a considerable reduction in disclosed vulnerabilities after the application of the SDL
    Apparently they don't have total confidence in it...

    Quote Originally Posted by The MS Banlist
    Any function in this section's tables must be replaced with a more secure version
    Oops, there's 30 or so violations on the ban from the first three categories alone in modules new to Win7.

    Quote Originally Posted by The MS Banlist
    Obviously, you cannot replace a banned API with another banned API
    Introducing StrSafe, by our definition it's no safer than what you've got now. I guess they forgot it's built on top of the "banned" CRT functions. Well, unless you happen to know the magical mystery define that's not documented anywhere.

Page 2 of 3 FirstFirst 123 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. coding help? (functions)
    By believe in forum C Programming
    Replies: 2
    Last Post: 06-03-2007, 11:54 AM
  2. comment on my coding style and if i use functions well
    By Unregistered in forum C++ Programming
    Replies: 14
    Last Post: 03-09-2002, 06:24 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21