Hacker cashes in on djbdns' $1,000 security guarantee

H_TeXMeX_H · 03-13-2009, 04:27 AM

Quote:

Originally Posted by alan_ri

you'll see that this patch isn't preventing buffer overflow completly,only in a way.
There are more examples in the link I posted before.

Well, you might be right, and if you fix it up maybe you'll get $1000 too ?

alan_ri · 03-13-2009, 05:26 AM

Quote:

Originally Posted by H_TeXMeX_H

Well, you might be right, and if you fix it up maybe you'll get $1000 too ?

Maybe I will.

ErV · 03-13-2009, 05:55 AM

Quote:

Originally Posted by H_TeXMeX_H

Well, that's exactly what's happening here, before the fix there was likely insufficient bounds checking.

Code:

-    if (dlen <= 128)
+    if ((dlen <= 128) && (response_len < 16384))
       if (name_num < NAMES) {
        byte_copy(name[name_num],dlen,d);
        name_ptr[name_num] = response_len;

I think the red line is somewhat dangerous without bounds checking on response_len first.

Fragment mentioned in patch is extremely short and it DOESN'T deal with buffers associated response_len. Buffer used in conjuction with response_len could be happily overrun before(or after) that code fragment - even despite checking. Full source code (at least file) required to make further statements about buffer overruns in this code fragment.

Oh, and red line ISN't dangerous. You can see that value of response_len is being stored at the offset of name_num. What happens with this value later is unclear. "name_num" was checked even before patch was applied - unless I forgot patch file syntax, "red line" isn't modified by patch, and sanity check for name_num isn't added by patch either (it existed before patch). So patch doesn't affect risk of bufer overrun at "red line". Maybe it fixes possibility of buffer overrun in some other place (for buffers associated with response_len), but to check this, full code fragment required.