post-page

Programmers – Please be responsible!!

13
responses
by
 
on
June 1st, 2005
in
General

If you are a programmer and have written ANY code, you know that bugs are a part of life. If you have written a substantial amount of code, you know that bugs can get out of hand, forgotten and can become serious flaws or vulnerabilities in your software/scripts.

If you find a script, program or document to be particularly vulnerable, please take the time to make the programmer(s) aware that there is a problem with their program that should be fixed immiediately, BEFORE announcing it to the wide world. New vulnerabilities are always being found and older code always falls victim to newer exploits.

Stop complaining and be respectful. Instead of telling the world how to hack into a blog using a vulnerability, spend that time writing a small fix for it or at least emailing the person involved. This “beating the chest” is even more incredulous when a fellow programmer is the culprit.

[EDIT] While you are being responsible, quit deleting the (respectable) comments that well meaning people leave on your posts. It makes you look guilty and really makes you look bad. If you have jumped the gun, take your punches and move on.

Also, while I am being responsible myself, if you are using the “Advanced Contextual Search ” for WordPress from this blog, please visit that link again, re-download the source and update the hack (or completely remove it from your site). A very serious vulnerability with this hack was unscrupulously reported to me this afternoon.

heading
13
Responses

 

Comments

  1. Kates (3 comments.) says:

    Ugh. Through the heart.

  2. Ensellitis (2 comments.) says:

    Thank you for saying what I have always thought.

  3. Brian Benzinger (1 comments.) says:

    You said it! Man have I always disliked that. I think people get too excited about finding something that they want to get recognition for it. So they tell the world. I could be wrong though. Thank you for saying this, how true it is.

  4. Martin Geisler (3 comments.) says:

    Is this related to my recent post about SQL injection attacks where I say that the Advanced Contextual Search plugin is open for attack?

    I made a comment about the problem just before publishing it on my site — now the comment is gone and the plugins is supposed to have been updated. I cannot find any difference between the download I made yesterday and today (and $_GET['next_value'] still seems unprotected).

  5. Ensellitis (2 comments.) says:

    I really don’t think it has to do with you. As you said you made it aware to the programmers/scripters before posting it. But there are other people that will make a post or announcement before the bug/vulnerability is even know about (some people download just to do this) just to make them selves look good…

  6. Martin Geisler (3 comments.) says:

    Yeah, but I made them aware by posting a commont on their blogs instead of sending an email. I didn’t think much of it, I just wanted to let them know, and seeing all the user support going on in the comments I picked that place as my point of contact.

  7. Sebbi (3 comments.) says:

    There still is a sql injection problem with your search plugin … there is a “quote_smart” around one _GET['q'] and another _GET['next_value'], but two more occurences aren’t protected this way …

    Greetings, Sebbi

  8. Mark (118 comments.) says:

    Sebbi, thanks for the catch, fixed.

  9. Denis de Bernardy (7 comments.) says:

    to which extent does this fit for wordpress? in wp-settings.php, you’ll find the lines:


    if ( !get_magic_quotes_gpc() ) {
    $_GET = add_magic_quotes($_GET );
    $_POST = add_magic_quotes($_POST );
    $_COOKIE = add_magic_quotes($_COOKIE);
    $_SERVER = add_magic_quotes($_SERVER);
    }

  10. Martin Geisler (3 comments.) says:

    I admit that I hadn’t seen this, and for a moment I thought that this would save us — but no: $_GET['next_value'] is used as one of the values for the LIMIT clause, and it is used without being put inside quotes in the query.

    So even though the variable will have all single and double quotes escaped the problem remains, for you don’t have to put quotes into it at all to wrech havoc.

  11. Stuart Caie (1 comments.) says:

    Talking of responsibility, I don’t particularly like people using scripting languages and giving out the fruits of their creation before they actually understand the security implications of bad code.

    The number one fact about an exploitable bug is that IT EXISTS. If anyone discovers it, everyone should be told about it as soon as possible, because it’s best to presume that less scrupulous people already know about it and, as you advocate, have been keeping it quiet from the general populous.

    You were given adequate warning that you had a bug. Run with it and fix it ASAP. Meanwhile, public notification allows the public to take decisive action – remove the buggy, exploitable plugin immediately and do not re-install it until the vulnerability has been fixed.

  12. Mark (118 comments.) says:

    You were given adequate warning that you had a bug

    Did you even READ the above post???

  13. Michail (1 comments.) says:

    Well spoken. The culprit is always a “fellow” programmer! But a sad fellow it must be who thinks he’s the man ’cause he let the world know he’s found a bug.
    Stuart, implications of bad code? There’s no such thing as good code. Software is always “a work in progress”. So what if there are a few bugs? You get what you pay for. Only fools claim their software has no bugs. Most people who exploit these “bugs” are in fact kids who learn about them when they’re published prematurely and then search the internet for old versions that they can crack. If there’s a pro after you, he’ll get the job done unless you have the resources and know-how to stop him. Anyway, if the less scrupulous already know it, why tempt the rest? Letting people know there’s a bug is different to shouting to the whole world what the bug is.



Obviously Powered by WordPress. © 2003-2013

page counter
css.php