[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