Hacker cashes in on djbdns' $1,000 security guarantee
Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Actually I guess it would work in his favour really. Saying one security bug in a decade suggests a more secure product than one just tagged as "I think this is secure"... No idea what kind of a commercial slant he has on djbdns though... maybe more so in the near future.
Last edited by unSpawn; 03-06-2009 at 01:09 PM.
Reason: Moderation
Actually I guess it would work in his favour really.
Most definitely. I don't know if he pictured this when he came up with the $1,000 reward, but if he did then he's pure genius. The awesome thing is that even though it's a marketing ploy, it's still based on actual proven results, which in today's world is not a common sight.
Am I being a muppet then? How is that not an overflow?
I'm no expert, but I agree that it is an overflow prevention. It's checking to see that 'response_len < 16384', not sure what response_len is but it seems to be a length, and so it's probably preventing an overflow of 'response', if it exists.
All I wanted to say is that I think that the code in question doesn't stop a buffer overflow by itself and I based my answer on what I've read here.Correct me if I'm wrong.
All I wanted to say is that I think that the code in question doesn't stop a buffer overflow by itself and I based my answer on what I've read here.Correct me if I'm wrong.
Quote:
A buffer overflow occurs when data written to a buffer, due to insufficient bounds checking, corrupts data values in memory addresses adjacent to the allocated buffer. Most commonly this occurs when copying strings of characters from one buffer to another.
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.
I think the red line is somewhat dangerous without bounds checking on response_len first.
Hi Tex,
Somehow I didn't saw your reply until now.
Well,I'd say that response_len checking is all that this patch is about,so of course that red line without bounds checking on response_len first would be dangerous,but that's not what I had in mind.
If you read this:
Quote:
A technically inclined and malicious user may exploit stack-based buffer overflows to manipulate the program in one of several ways:
By overwriting a local variable that is near the buffer in memory on the stack to change the behaviour of the program which may benefit the attacker.
By overwriting the return address in a stack frame. Once the function returns, execution will resume at the return address as specified by the attacker, usually a user input filled buffer.
By overwriting a function pointer,or exception handler, which is subsequently executed.
or this:
Quote:
Exploitation is performed by corrupting this data in specific ways to cause the application to overwrite internal structures such as linked list pointers.
then 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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.