Re: IrfanView is not affected by the MS JPEG vulnerability.

On Tue, 10 Jan 2006 09:32:22 +0000, Martin Brown
<|||newspam|||@nezumi.demon.co.uk> wrote:

>JB wrote:
>
>> I'd say that C *allows* sloppy coding (as does any language) but in
>> what way does it *encourage* it (any more than any other language)?
>
>Most of the main buffer overflow vulnerabilities stem from the C mindset
>inherent in the K&R example for strcopy() = while (*s++ = *t++);

Which is, of course, a perfectly correct implementation of strcpy.
It's unsafe *usage* of strcpy that causes the problem, not this
implementation.

>
>> It's perfectly possible to write secure well-engineered code in C.
>
>But much more difficult to be sure it does what you really intend than
>in other strongly typed languages like Ada, Algol, Modula2 or Pascal.
>>
>> The problems caused by sloppy coding in C may be different from those
>> caused by sloppy programming in, say, Java, but it's still just as
>> possible to write bad code in Java.
>
>It is always possible to write bad code in any language.
>
>C merely permits a lot more human errors to compile without comment. It
>was much worse in the past when compilers would let through obvious
>errors detectable by static analysis. Classics like eg:
>
>x=0;
>if (x = 0) printf("hello world");
>
>It was always amusing to run production C code through new versions of
>lint to see how many new MFUs would show up.

That's not really so much the case these days, however. I agree it
was pretty bad before ANSI C, with no function prototypes etc., but
most compilers are now pretty good at picking up the well-known C
gotchas.

The *vast* majority of the bugs I see in production code are language
independant - errors of logic rather than falling into C linguistic
traps.

/JB
--
jbjb AT uk2 DOT net
.

Relevant Pages

  • Re: Privilege-escalation attacks on NT-based Windows are unfixable
    ... the C language and libraries are flawed ... >also pin a good deal of the blame on the flawed language itself, ... If I have a program that doesn't check a buffer passed into strcpy, ... should, as a secure programmer, be aware that every time you call strcpy, you ...
    (comp.security.misc)
  • Re: Privilege-escalation attacks on NT-based Windows are unfixable
    ... the C language and libraries are flawed ... >also pin a good deal of the blame on the flawed language itself, ... If I have a program that doesn't check a buffer passed into strcpy, ... should, as a secure programmer, be aware that every time you call strcpy, you ...
    (comp.os.ms-windows.nt.admin.security)
  • Re: It works without stdio.h !!
    ... most C compilers will assume that a function that has no prototype is an ... extern int, and since you only specify functions that live in the C library, an unresolved ... never declare a variable of type char unless you well and truly believe you need to be ... strcpy, strcat, sprintf etc. with it. ...
    (microsoft.public.vc.mfc)
  • Re: Variable declaration and initialisation
    ... if die; strcpy (p, string1); ... if die(); strcpy ... Some compilers are able to detect and warn about the use ...
    (comp.lang.c)
  • Re: adding #include header file
    ... Also, C is a different language than C#, while there are similarities, they ... > strcpy;> strcpy; ... > zProcess (&parm); // dll function call that modifies certain members> of parm ...
    (microsoft.public.dotnet.languages.csharp)