[CLUE-Tech] OT: C code security - what to look for?

Dale K. Hawkins dhawkins at cdrgts.com
Tue Aug 12 12:25:59 MDT 2003


Matt Gushee <matt at gushee.net> writes:

> Also: I understand in principle the (possible) need to check the
> results, but what about them would need to be check, exactly?

Just that they do not return NULL or something.  I again confess
ignorance as to the OCaml allocation paradigm.

>> (check your invariants).  The C++ FAQs has a good section on this.
>
> URL?

Not sure.  I have the book.  Try google.  I can look later, too.

>> > value ml_image_dline(value *argv, int argn) {
>> > 
>> >   assert(argn == 7 && "Wrong number of arguments given to ml_image_dline");
>
> Sounds like a good idea. Is that assert function standard in ANSI C? Or
> is it at least portable among "normal" systems (whatever that means).

Yes.  Assert (from #include <assert.h> will abort the program though.
The assert is just the simplest, prevent a hacker type fix.  You might
want to use the OCaml exception mechanism.

> Ah. Do you mean that one could circumvent file permissions with this
> code? That would indeed be something to watch out for, I guess.

Well not necessarily circumvent, but it does potentially allow file
system access via the web -- one of the classic methods to crack a box.

> Maybe I should do something like
>
>   #ifdef ALLOW_FILE_ACCESS

Or create a config variable to control access.  Or even use chroot.

I am also not saying that this is instantly exploitable.  I merely
want to raise the awareness around such areas.

> There's that word again: 'unchecked'. It doesn't sound good, but I'm not
> picturing exactly what sort of problems it entails.
>
>> B.  Send an invalid image reference to a given function call (this
>>     would require creating a way to verify an image handle is truly
>>     valid before doing any operations).

[[I will have to read and comment on the rest later.  Lunch time.]]

-Dale



More information about the clue-tech mailing list