Slashdot Mirror


GdkPixbuf Suffers Image Decoding Vulnerabilities

DNAspark99 writes "It seems Multiple vulnerabilities have been reported in GdkPixbuf, which can be exploited by malicious people to DoS (Denial of Service), and potentially compromise a vulnerable system. Personally, I wasn't concerned about this until I ran 'ldd firefox-bin | grep libgdk_pixbuf'" There's no official patch yet, but the article notes several Linux vendors have issued updates. Worth keeping an eye for those who use libgdk_pixbuf under other Unix-style operating systems as well.

291 comments

  1. Nothing to see here... by gnuman99 · · Score: 3, Insightful

    More bugs. More fixes. More patches. This is the software cycle...

    1. Re:Nothing to see here... by tehshen · · Score: 3, Funny

      What would you prefer? To stop the patches and fixes, you want no new bugs. To have no new bugs, the product won't evolve. If you want a moving-forward product, don't complain :)

      --
      Guy asked me for a quarter for a cup of coffee. So I bit him.
    2. Re:Nothing to see here... by Anonymous Coward · · Score: 1, Informative



      Who says the parent poster is complaining?

      The parent poster was just making an observation... he/she was not passing judgement.

    3. Re:Nothing to see here... by cyb97 · · Score: 2, Insightful

      Trying to secondguess what the OP meant (ofcourse influenced by my own opinion), every bug or patch isn't really slashdot-worthy. This one certainly ain't groundbreaking news...

    4. Re:Nothing to see here... by starnix · · Score: 1

      ...because Slashdot holds itself to a higher standard when reporting news.... Right?

    5. Re:Nothing to see here... by AHumbleOpinion · · Score: 1

      Given other recent bugs that should be:

      More bugs. More fixes. More patches. Not from Microsoft so there is nothing to exploit politically. Nothing to see here ... ;-)

  2. gnome uses this by kinko · · Score: 4, Insightful

    If you're not aware, gnome2 uses this library, so any gtk2/gnome2 applications you use are probably linked against libgdk_pixbuf.

    update your systems...

    1. Re:gnome uses this by Anonymous Coward · · Score: 0

      I hate the phrase "linked against". Why shouldnt it be "linked with"?

    2. Re:gnome uses this by http · · Score: 4, Informative

      I tried "apt-get --dry-run --purge remove libgdk-pixbuf2 libgdk-pixbuf-gnome2" and the list of packages was _long_. I do not have a gnome-heavy system, either. Some choice selections:
      bonobo
      galeon
      gdm
      gnome-control-center
      gnome-help
      gnome-panel
      gnome-session
      gnome-utils
      libgnomeprint-bin
      nautilus
      rep-gtk-gnome
      sawfish-gnome
      xchat-gnome

      It's a biggie, all right.

      --
      If opportunity came disguised as temptation, one knock would be enough.
      3^2 * 67^1 * 977^1
    3. Re:gnome uses this by TheAwfulTruth · · Score: 1

      Depends.

      If you are talking about the executable in the abstract, compiled against dynamically linked library, then no, it is only linked AGAINST the lib (Or linked with the lib header). It only gets linked WITH the lib itself at run-time.

      So when people are talking about programs as they exist on disk such as in a distribution or as they are being doanloaded, then it's usually talked about as the code has been linked against the lib, in that state it is not linked with the lib. (Course there are programs that ARE "statically" linked WITH libraries at compile time, but not in this case)

      --
      Contrary to popular belief, coding is not all free blow-jobs and beer. Those things cost MONEY!
    4. Re:gnome uses this by Anonymous Coward · · Score: 1, Informative

      I tried "apt-get --dry-run --purge remove libgdk-pixbuf2 libgdk-pixbuf-gnome2" and the list of packages was _long_. I do not have a gnome-heavy system, either.

      Well yeah, the library is part of Gtk+ - anything using Gtk+ 2.x uses it. Nothing to do with Gnome specifically.

    5. Re:gnome uses this by Anonymous Coward · · Score: 0

      Ahh, I see you were compiled with -lidiot.

      Why comment on something you obviously know very litle about?

  3. Somebody is busy ... by crimethinker · · Score: 5, Insightful
    I think this is the fourth vulnerability related to image decoding I've seen in the past month or so. Methinks somebody is doing a thorough code review of open source image libraries, the stolen NT code (remember the Windows BMP vuln?), and, where source can't be obtained, thinking about where it might be vulnerable. I just wish people with that much determination would concentrate on fixing the bugs, instead of exploiting them ... so much wasted talent.

    sigh Time to tell the idealist in me to STFU.

    -paul

    --
    Pistol caliber is like religion: everyone has their favourite, and theirs is the only right choice.
    1. Re:Somebody is busy ... by Anonymous Coward · · Score: 5, Informative

      The one who found this vuln is Chris Evans, as known
      as the vsftpd author (http://vsftpd.beasts.org/), and
      here (http://scary.beasts.org/security/) are other bugs he found.

    2. Re:Somebody is busy ... by BeBoxer · · Score: 4, Insightful

      I just wish people with that much determination would concentrate on fixing the bugs, instead of exploiting them ... so much wasted talent.

      What we really need is a web page summarizing all the recent bugs in media decoding (mpg123 I think just had one) as a "how not to program" guide and then make it mandatory reading to get a sourceforge account. I think it's great folks are out looking for these bugs, but it's an embarrasement that there are this many being found so quickly. To me that indicates that there are a crapload of them out there.

      It makes me want to go on vacation for six months and do one upgrade when I get back. Instead of doing one a day for the next six months.

    3. Re: Somebody is busy ... by Alwin+Henseler · · Score: 1
      ...fourth vulnerability related to image decoding I've seen in the past month...

      Yes, yes, people are starting to notice...

      Methinks somebody is doing a thorough code review (..)

      Naahhh, it must be a global conspiracy! We just didn't find out yet who is The Evil One behind all this...

    4. Re:Somebody is busy ... by PitaBred · · Score: 3, Insightful

      The thing is, you now know about the vulnerability. I'd rather know about it and fix it than not know about it and let someone exploit it. It's a GOOD thing that people are finding these and reporting them. They'll found either way...

    5. Re:Somebody is busy ... by ZuperDee · · Score: 3, Insightful

      I just wish people with that much determination would concentrate on fixing the bugs, instead of exploiting them ... so much wasted talent.

      Why should they?!? If I ask a question, why should I also have to provide an answer? That is a stupid attitude to have. If everyone who asked questions had the answers, there'd be no questions to ask.

      Likewise, why look a gift horse in the mouth when he points out a vulnerability like that? Exploiting is a different art from coding to many people. Maybe it just so happens that some people are better at seeing things that others don't catch?

      And don't blame the tools, either. I hear too often people saying things like "if only it were in Java instead of C++, this would not be a problem." A poor workman always blames his tools. A poor musician can ALWAYS say "if only I had a better instrument, I could be a better musician." One simple word for that: Balderdash.

    6. Re:Somebody is busy ... by Anonymous Coward · · Score: 0

      I Just wish people with that much determination would concentrate on fixing the bugs, instead of exploiting them ...

      These are bugs they are fixing...really nasty bugs that result in your computer being compomised which is probably one of the worst kind of bugs I can think of.

    7. Re:Somebody is busy ... by bman08 · · Score: 0, Redundant

      I really dislike cockroaches and scorpions (it's the babies on the back thing), but the worst kinds bugs I can think of are earwigs. They compromise your ears!!!

    8. Re: Somebody is busy ... by Anonymous Coward · · Score: 1, Funny

      Who's behind it? Probably either Bush or Microsoft.

    9. Re:Somebody is busy ... by iabervon · · Score: 3, Informative

      You need to write exploits in order to test whether you've actually fixed the bugs, and in order to determine whether the code is actually correct for some reason you're not seeing.

      It is often the case that support for some functionality which is buggy in one implementation will be buggy in other implementations as well, so it is pretty common in general for a lot of similar bugs to turn up at the same time.

    10. Re:Somebody is busy ... by runderwo · · Score: 1
      It makes me want to go on vacation for six months and do one upgrade when I get back. Instead of doing one a day for the next six months.
      Why not just set up automated security updates?

    11. Re:Somebody is busy ... by cowbutt · · Score: 2, Insightful
      Methinks somebody is doing a thorough code review of open source image libraries, the stolen NT code (remember the Windows BMP vuln?), and, where source can't be obtained, thinking about where it might be vulnerable.

      I wouldn't be surprised if people are just testing the proof-of-concept demonstration files intended to break other image decoding code and finding that it breaks their code too, maybe in a slightly different way. It's not uncommon for separate programmers to make the same thinkos even if they've never seen each other's code (and especially if the original data spec is unclear, undefined or ambiguous on a given point).

      The scary thing is that the sorts of problem we're seeing here apply to any "active" data format - i.e. one where the file isn't simply read and taken as-is (e.g. a plain text file), but is actually made up of "commands" which are interpreted as the file is used. We've seen similar problems with PostScript, PDF, MP3, wmv and probably more besides. The thing about this one is that short of HTML, JPEGs are probably the single most-commonly accessed type of active file - and from sources which may not be trustworthy too!

      --

    12. Re:Somebody is busy ... by Anonymous Coward · · Score: 0

      why not install yum or apt and set up a daily cron job then you don't have to do anything ;-)

    13. Re: Somebody is busy ... by Anonymous Coward · · Score: 0

      Or you could be like the rest of us, and blame Bush and Microsoft for things they're actually responsible for.

    14. Re:Somebody is busy ... by roadrunnerro · · Score: 1

      Analogies are not your strong suite it seems... A good musician _will_ suck if he's forced to use a diacorded clavecin instead of a piano.

      Newsflash: overflow & friends are much more common in C/C++ apps than in other languages, like those running on .NET, Java or the OP in Delphi. Things like compiling with the GS flag help, but it's the language itself that makes programmers prone to miss potential bugs.

    15. Re: Somebody is busy ... by BlackHawk-666 · · Score: 1

      Or a scary new lifeform that is an insane mix of the two, henceforth to be known as MicroBush. MicroBush is a particularly dangerous tech company with the ability to wage real war against it's competitors.

      --
      All those moments will be lost in time, like tears in rain.
    16. Re:Somebody is busy ... by discord5 · · Score: 1
      I just wish people with that much determination would concentrate on fixing the bugs, instead of exploiting them ... so much wasted talent.

      Despite that some people tend to abuse these faults for bad things, I think it's a good thing that there are people out there finding holes in existing code. It can only result in better code, and better systems.

      Then again, I may still believe that the human race is a species striving for self-improvement, rather than self-destruction.

    17. Re:Somebody is busy ... by k98sven · · Score: 1

      I just wish people with that much determination would concentrate on fixing the bugs, instead of exploiting them ... so much wasted talent.

      Who are you talking about? The exploit-writers or the people finding vunerabilities. There are plenty of the latter who don't write exploits. In these recent cases that has been the case too. Not of an exploit being found in the wild, but of a vunerability to exploitation being found.

      That said, the people finding vunerabilities are doing a good and useful job. It's often harder to find a bug than to fix one.

      Buffer exploits are definitely in the category of being more difficult to anticipate than to fix. Usually adding a simple test is all that's need to fix them.

      (Perhaps you haven't noticed, but practically all these vunerabilities are fixed within hours after being found.)

  4. What the hell by Anonymous Coward · · Score: 1, Interesting

    And here I was all like "my God, that's pathetic, Microsoft can't even make a JPEG parser without buffer overflows that compromise the user".

    Now it seems this is universal, or at the very least universal outside the macintosh world. Are the people who write graphics libraries just not trying very hard or something?

    1. Re:What the hell by Anonymous Coward · · Score: 4, Insightful

      Well, they tend to be writing in C, and concerned about "performance". They thus leave out vital buffer checks. Given that computers are now 3000 times faster than when I was a lad, there's no excuse, any inefficiency is easily compensated for by the "ridiculous speed" of modern computers.

      Either learn to write safe C or switch to a safer language.

    2. Re:What the hell by tehshen · · Score: 1

      No, it's just that the people who find exploits are trying harder.

      --
      Guy asked me for a quarter for a cup of coffee. So I bit him.
    3. Re:What the hell by pclminion · · Score: 4, Insightful
      Are the people who write graphics libraries just not trying very hard or something?

      Uhhh, no. It is simply "in vogue" to look for vulnerabilities in image format parsers at the moment. Is the trend not obvious?

      Soon all the major image libraries will have been examined, all the bugs fixed, and the security gurus will move on to other things. And we'll all benefit from that, because the code will be fixed.

      Bitching is counterproductive, don't you think?

    4. Re:What the hell by Anonymous Coward · · Score: 0

      I may be talking out of my behind here, but -

      from what I heard, buffer overflow exploits happen more often on x86 than PPC because of the different locations that PC and stack pointer have in memory.

      I read that on the intarweb, so it must be true - can anyone with more assembly knowledge maybe enlighten us?

    5. Re:What the hell by downbad · · Score: 1

      libgdk_pixbuf and mozilla run on OSX, too.

    6. Re:What the hell by Seq · · Score: 5, Insightful

      I find that alot of people I've worked with in software development have a "get it working, clean it up later" attitude. Usually basic error checking gets thrown in, but "hardcore" security often gets put aside in favour of other projects that need to be done. Thus, I think we end up with a fair amount of possibly shoddy code.

      I've never done an audit, because I'm trying to write good code, and it's all I can do to be as "productive" as the others.

      I don't think anybody seriously thinks "man, that could be a huge problem! well, nobody will notice".

      --
      -- Seq
    7. Re:What the hell by cyb97 · · Score: 4, Insightful

      well eventhough the computers are zillion times faster, the datastructures they have to deal with have gotten zillion times bigger and/or more complex.
      Solving algorithm-deficiencies by throwing more iron at it is a short-term solution that is bound to come back and bite you in the tail sooner or later.

      Learn to write safe C and make sure your algorithms are sound and healthy.

    8. Re:What the hell by fitten · · Score: 3, Insightful

      There are a number of very easy things you can do while coding to make it more secure. For example, avoid any non- "n" string function. Just get used to typing and using strncat and snprintf and the like instead of the unchecked ones. Little things like that can actually go a pretty long way.

    9. Re:What the hell by fitten · · Score: 1

      Yep... pretty common attitude... for exaxmple, all the junk in the Microsoft JPEG exploit thread the other day... It's pretty ironic.

      Tons of one liner sayings come to mind...

    10. Re:What the hell by evslin · · Score: 0, Troll

      Now it seems this is universal, or at the very least universal outside the macintosh world.

      I fail to see the difference!

      /ducks

    11. Re:What the hell by Anonymous Coward · · Score: 1, Funny

      Just get used to typing and using strncat and snprintf and the like instead of the unchecked ones.

      I used those in a CS project for school once and I got the project back with my grade marked down for using those! Apparently the stupid ass TA who graded it didn't know what the hell those were and marked me down for misspelling some other function.

      Hopefully his visa expired by now...good riddance...

    12. Re:What the hell by Anonymous Coward · · Score: 3, Funny

      Personally I think C is much too slow.

      Relying on high level languages like C seems like a good idea because of development time and security but eventually program complexity will outpace hardware speed increases and you will be screwed!

      A real programmer doesn't need to waste resources on bloated handholding crap like "C". A real programmer uses assembly to avoid writing bloated code!

    13. Re:What the hell by pavon · · Score: 2, Insightful

      Graphic proccessing is one of the places where the speed is needed. Yes computers have gotten 1000 times faster but modern GUIs do 1000 times more graphics computations than they use to. Concider the fact that every single gtk/gnome widget drawn on your screen uses this library (yay themes) and it becomes apparrent that it has to be written for speed, so going to a high level language is not an option. There are many other reasons that GTK uses C, the main one being that while everyone is moving to high level languages, they are all moving to different ones. Therefore, GTK has to be written in C since that is what all the other languages can link against.

      Second, it likely wasn't that they intentionally left out checks on purpose for speed, but just missed one - probably weren't think about someone attempting to DOS thier graphics library. It happens when you write code. I am a decent programmer and have never found an integer overflow or memory access error in any C code I wrote (after shipping it), but I am not arrogant enough to think that there are not any in there waiting to be discovered. It isn't insightfull to say that if everyone programmmed perfectly then we wouldn't have any bugs - it is unrealistic.

      Lastly, even if you did use a high level language, the programmer that overlooked thisp problem in C would still overlook it in the higher level lanugage as well. It would likely result in an uncaught exception, and the program would likely terminate. So this would still be a bug - just not a security hole, since it couldn't result in executing arbitrary code.

      Higher level lanugagues can help make a program more secure, and are a good idea for that reason. But as long as human beings are the ones writting code, mistakes and oversights will happen, and patches are something you will have to learn to live with.

    14. Re:What the hell by Anonymous Coward · · Score: 0

      Yeah, I have to agree here.

      Is the increase in development time and security really worth the speed hit you take for using new fangled languages like C?

      I don't think so. Any project using thse trendy new languages popular with the PHBs is doomed to failure. I'm just going to keep using assembly forever!

    15. Re:What the hell by dvdeug · · Score: 1

      Learn to write safe C and make sure your algorithms are sound and healthy.

      You know what they said when they came out with Fortran (for general programming) and later C (for systems programming). "Learn to write safe assembly and make sure your algorithms are sound and healthy, instead of taking the speed hit of using a high-level language." Sigh. How many C exploits is it going to take to learn that this 10 or 15% is worth it?

    16. Re:What the hell by malfunct · · Score: 2, Interesting

      Or more likely is they all have a similar structure inside and so after finding one vulnerability it wasn't hard to morph it to the other jpeg libs that are out there.

      --

      "You can now flame me, I am full of love,"

    17. Re:What the hell by argent · · Score: 1

      And here I was all like "my God, that's pathetic, Microsoft can't even make a JPEG parser without buffer overflows that compromise the user".

      Why? Buffer overflows can be fixed without breaking software that depends on the flaw, so Microsoft can release a patch without having to get political about it.

      The real hard problems are when the flaw is baked in to the interfaces and protocols that people are using, like IP-based security in the old UNIX r*suite apllications that many people *still* use instead of ssh, or the flaws in Internet Explorer that Microsoft can't address because they have too much face tied up in them after the monopoly trials, or the lunatic complexity in sendmail and Win32.

      (yeh, there's plenty of crow for everyone, though Microsoft's seems to be rottenest)

    18. Re:What the hell by Anonymous Coward · · Score: 1, Informative

      Now it seems this is universal, or at the very least universal outside the macintosh world.

      Wtf, what does that mean? It's in the mac world too. Have you seen all the mac vulns that have come out? Just last week they had a few moderately bad ones. And yes they had had remote exploits etc. in the past. There is no OS distribution in existence today that's over five years old that has not had remote exploits in the default install.

    19. Re:What the hell by be-fan · · Score: 2, Informative

      In a language without pointers, array-bounds checks impose a 1-3% performance hit. This is because advanced optimizers can usually remove most of the array-bounds checks. In practice, safe natively compiled languages (Ocaml, Lisp) can get within 10% - 20% the performance of C. 10% - 20% for the sake of security is a trade-off I'm willing to make. Obviously, the current C recommendation of "learn to write secure code in a language that encourages you not to" isn't working, because buffer-overflow vulnerabilities are rampant. It's time to throw that idea out the window.

      --
      A deep unwavering belief is a sure sign you're missing something...
    20. Re:What the hell by Anonymous Coward · · Score: 1, Interesting

      I was actually involved in developping a webapp in which I noticed a vulnerability that'd allow people to bypass the password and security checks and modify arbitrary data in the database. I pointed this out to the lead developper, and he said it'll be too much work to fix, and probably no one will ever notice.

      Posting AC so that it's not obvious what webapp I'm talking about, hopefully sparing the DB from any attacks.

    21. Re:What the hell by bit01 · · Score: 1

      Yep, it is easy to, whenever writing any line of code, to ask "How can this line, by accident or design, be compromised?" It is not necessary to have a program global view except to stop DOS attacks caused by individual lines of code bailing out.

      Too many slack, so called "productive" programmers, don't do that and push their problems on to the rest of us.

      One common example in C is printf's/scanf's where the programmer doesn't check the status return. Is it so hard to wrapper it and check? I've lost count of the number of programs that behave badly if the disk is full or an input file is truncated, both common occurrences. Grrr.

      ---

      Patents restrict distribution by definition and are incompatible with standards which by definition promote distribution. Say no to patents in standards!

    22. Re:What the hell by eraserewind · · Score: 1
      Learn to write safe C and make sure your algorithms are sound and healthy.
      Jeez, even as a C programmer, that doesn't seem like the solution to me. Using a safer language and/or having better OS protection seem like the way to go.
    23. Re:What the hell by Antique+Geekmeister · · Score: 2, Insightful

      And they're not trying very hard. A new patentable algorithm is worth money. A performance improvement is also worth money and makes your software better. Most security measures, such as checking return values and carefully allocating memory or evaluating possible sizes of inputs, cost CPU time, slow your systems, and cost time to do. And they're often best understood by the most expensive programmers on a team, not the new guys and interns handed these new development problems, so they get tacked on only as an afterthought.

    24. Re:What the hell by urlgrey · · Score: 1

      Here, here.

      IMHO, this is a yet another example of the most dangerous line in security, "It's not like...."

      I'm sure in many cases these folks literally said to themselves something like, "It's not like someone's ever going to try to attack an image. That's just too much effort! / That doesn't make sense."

      Grrr. I guess expecting people to stop themselves mid-thought on that one is too much to ask though.

      --
      Running 'Nix is like owning a Lightsaber. It's "a more elegant weapon for a more civilized time."
    25. Re:What the hell by Anonymous Coward · · Score: 0

      alot of people

      "a lot".

    26. Re:What the hell by Anonymous Coward · · Score: 0

      Here, here.

      "Hear, hear!".

    27. Re:What the hell by Anonymous Coward · · Score: 0

      I'd rather see the people who can't write safe C code thrown out the window.

    28. Re:What the hell by Spy+Hunter · · Score: 1
      Solving programming-language deficiencies by chanting "write safer code" is much, much worse than solving algorithmic deficiencies by buying hardware. Besides, algorithmic problems aren't an argument against better languages such as Java. You can write the same algorithms in Java as in C, and they will perform about the same if you are marginally competent in both languages. C is obsolete and dangerous; checked buffers and garbage collection are the way of the future.

      Note: I am talking about programming for the desktop computers of today and tomorrow. For small embedded systems, C is still a viable (though risky) choice.

      --
      main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
    29. Re:What the hell by Anonymous Coward · · Score: 0

      better languages such as Java

      It has been a long time since I have heard the words "better" and "Java" in the same line.

      checked buffers and garbage collection are the way of the future

      while I agree that it would solve some problem now, don't you think that it will lead to problems later. If you have a generic garbage collector and people will get used to it and program more and more sloppily. This means that if a garbage collector gives you a performance hit of a few percent now, it might give you a much larger hit when the younger programmers that have never learned to program without one hit the market.

      IMHO it's always good to know something about the computer (by playing with assembly language for instance), before you move on to high level languages. To go one step further to even higher level languages, means that programmer will have even less contact with the machine under the hood.
      I think this is a bad thing. I want the guy writing my software to know how computers work!

    30. Re:What the hell by Spy+Hunter · · Score: 1

      I agree that people should learn C or assembly language in school, as part of their education on how computers work. That doesn't mean that C should be used for writing real programs for desktop computers.

      --
      main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
    31. Re:What the hell by IamTheRealMike · · Score: 1

      Yeah, indeed. If you look at some of the more serious ones they're actually insecure by design (things like the disk:// URL and auto-loaded URI handlers) rather than simple overflows. That's the sort of ActiveX debacle that Microsoft get slated for all the time, but when Apple does it the silence is deafening.

    32. Re:What the hell by Anonymous Coward · · Score: 0

      Sometimes even using bounds-checked functions such as strncpy isn't enough. You'll sometimes see something like strncpy(foo, bar, sizeof(bar)); which totally defeats the purpose, but it compiles so it must be correct, right?

      Sometimes bad code is just the result of a bad coder.

    33. Re:What the hell by Anonymous Coward · · Score: 0

      Assembly! What the hell! Real programmers code directly in binary. Long live the binary mouse! (left click = 0, right click = 1).

    34. Re:What the hell by Lars+T. · · Score: 1

      Click both simultaneously = Buffer Overflow

      --

      Lars T.

      To the guy who modded me down from perfect to terrible Karma - Apple haters still suck

  5. There will always be vulnerabilities by 2forshow · · Score: 3, Interesting

    There will always be vulnerabilities. Since people can't produce perfect code there will always be a way for someone to make a flaw into a vulnerability. Therefore there will always be patches and updates(relating to security measures). The only way to stop these flaws from becoming an issue, like this one, is to stop crackers. And good luck with that.

    --
    Free Ipods it's for real check out Wired then go to: http://www.freeiPods.com/default.aspx?referer=8533
    1. Re:There will always be vulnerabilities by Anonymous Coward · · Score: 0

      Or you could just stop using C.

      It's not 1978 anymore, you can switch to a more advanced language some day...

    2. Re:There will always be vulnerabilities by Anonymous Coward · · Score: 0

      C is vulnerable to buffer overflows unless you intentionally make your code invulnerable (go ahead and find a buffer overflow in vsftpd--coded in C, and I'll give you a million bucks) The fact is that this is a solved problem. People just opt not to solve it most of the time. Properly coded, C can be as secure as ADA.

      The problem is, the REALLY tricky security bugs have nothing to do with the language. It's bad implementations, poor design choices, etc. That can be done in any language, and it's usually hard to spot and harder to fix.

      Some people choose a programming language because it works, not because it's the hippest, most Javariffic thing out there. C works. So that's what I write my code in. And you're just wrong to think that means my code is automatically vulnerable to buffer overruns.

    3. Re:There will always be vulnerabilities by Anonymous Coward · · Score: 0
      Properly coded, C can be as secure as ADA.

      Improperly coded, ADA gives you a compile time error. Still secure. Any language is just as great as any other if you assume the programmer is God--our friend Alan Turing proved that. If you happen to be God, well that's great, Lord. But unfortunately not all of your creations are equally infallible as your Highest Grace, and it might be wise for us to use a programming language that protects us from ourselves.

      The problem is, the REALLY tricky security bugs have nothing to do with the language.

      But the really COMMON ones have everything to do with language.

    4. Re:There will always be vulnerabilities by Anonymous Coward · · Score: 0

      This is exactly why I laugh at all the *nix heads who bash M$. EVERY os from now till the end of time will have bugs. Every peice of code is under the microscope.

    5. Re:There will always be vulnerabilities by Anonymous Coward · · Score: 0

      After reading that, I love you, whoever you are, far more than is healthy.

  6. Time to switch by Anonymous Coward · · Score: 4, Funny

    Time to switch. Take back the Web.

    Vote against shoddy software with your clicks.

    1. Re:Time to switch by Anonymous Coward · · Score: 0

      They didn't have a download for my platform!

      What gives? When will they be releasing some ports?

    2. Re:Time to switch by Anonymous Coward · · Score: 0

      dont hold your breath, Im still waiting for them to release a version of this 'linux' program. I've heard so much about this 'linux'. None of them will run on my XP machine tho. I hope it doesn't cost more than a couple hundred dollars.

    3. Re:Time to switch by 1qa2ws3ed · · Score: 1

      here ( http://www.colinux.org/ ) is your linux for windows xp. and yes, it costs less than 200$.

    4. Re:Time to switch by Anonymous Coward · · Score: 0
      Please learn how to make links.
      <a href="http://www.colinux.org/">here</a> is your linux for windows xp
      (without any spaces put there by Slashdot) yields: here is your linux for windows xp

      If that's too much typing for you,
      <URL:http://www.colinux.org/>
      (without any spaces put there by Slashdot) yields: http://www.colinux.org/
    5. Re:Time to switch by Sunnan · · Score: 1

      IE has this bug, too.

    6. Re:Time to switch by Anonymous Coward · · Score: 0
  7. A challenge for search engines? by prestwich · · Score: 5, Interesting

    It strikes me that it would be a good use of any spare capacity some search engines might have to search for image headers on web sites, that are attempting to exploit these types of problems.

    1. Re:A challenge for search engines? by subsentio · · Score: 1

      Ha, ha, ha! Spare capacity. Good one!

    2. Re:A challenge for search engines? by Anonymous Coward · · Score: 0

      Yeah, because all those well-meaning search robots won't pay attention to robots.txt (and will make their user agent string look like IE).

  8. Ah, nuts. by Anonymous Coward · · Score: 0, Funny
    I guess this means I should start using Windows.

    /me ducks

  9. That's okay... by rackhamh · · Score: 0, Troll

    ... we can still blame Bill Gates:

    Source: dictionary.com

    bmp

    Microsoft Windows bitmap format.
    Bmp files may use run-length encoding. :P

    1. Re:That's okay... by rackhamh · · Score: 0, Offtopic

      P.S. You, the person who modded me a troll. That's right, you!

      Go get some sunshine. Play with a puppy dog. Rent a comedy (hint: look for boxes with bright colors).

      You can thank me later. :)

  10. Not exploitable in Firefox by sppavlov · · Score: 5, Informative

    The only places using gdk-pixbuf in Firefox for loading images are all for loading images from your local machine. No from-the-network code paths use gdk-pixbuf.

    1. Re:Not exploitable in Firefox by Kenja · · Score: 0, Flamebait

      check me on this, but dont "from-the-network" images get downloaded to cache and then opened? If so then gdk-pixbuf would still be used to load the local cached image for display.

      --

      "Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
    2. Re:Not exploitable in Firefox by benwb · · Score: 1

      I find it hard to believe that firefox is using more than one image rendering libray for each image type it supports.

    3. Re:Not exploitable in Firefox by sppavlov · · Score: 5, Informative

      Mozilla does not use gdk-pixbuf for drawing images -- stuart "pavlov" parmenter (mozilla image library owner)

    4. Re:Not exploitable in Firefox by Kenja · · Score: 1
      "Mozilla does not use gdk-pixbuf for drawing images -- stuart "pavlov" parmenter (mozilla image library owner)"

      Well ok then.

      --

      "Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
    5. Re:Not exploitable in Firefox by sppavlov · · Score: 5, Informative

      We only use a single code path for rendering images. We only use gdk-pixbuf to decode GNOME images to find icons for mimetypes.

    6. Re:Not exploitable in Firefox by Mike+Shaver · · Score: 4, Informative

      Firefox uses gdkpixbuf for system MIME-type icons and window icons, which are loaded from the local system (GNOME icons or the firefox distribution). It does not use gdkpixbuf for decoding or displaying web-fetched images; it uses the Mozilla cross-platform image library (libpr0n), calling out to libpng, libjpeg and libgif as required underneath.

      Mike

    7. Re:Not exploitable in Firefox by poot_rootbeer · · Score: 0, Flamebait


      So Firefox doesn't ever save an image file that was HTTP'd off the network to a cache directory and load it from disk as needed?

    8. Re:Not exploitable in Firefox by asa · · Score: 4, Informative

      "So Firefox doesn't ever save an image file that was HTTP'd off the network to a cache directory and load it from disk as needed?"

      It uses libpr0n, Gecko's cross-platform rendering engine to load those images from disk. gdkpixbuf is not used for displaying remote content, even cached remote content.

      --Asa

    9. Re:Not exploitable in Firefox by LiquidCoooled · · Score: 1

      Could you possibly explain to us where about Mozilla *does* use this library?

      As far as you are concerned, is this a serious issue?

      --
      liqbase :: faster than paper
    10. Re:Not exploitable in Firefox by macsuibhne · · Score: 3, Interesting

      Props to the Mozilla geeks for the naming scheme (this would have been mod points if I had any).

      Tony.

      --
      -- "Quis custodiet ipsos custodes?" -- Juvenal
    11. Re:Not exploitable in Firefox by mrchaotica · · Score: 1

      I second LiquidCooled: where does Mozilla use gdk-pixbuf?

      Also, if it doesn't use it to draw images on web pages, what does it use? And (aside from the vulnerability) why are two different image libraries used?

      --

      "[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz

    12. Re:Not exploitable in Firefox by Compenguin · · Score: 3, Informative

      Mozilla uses gdk-pixbuf via gtk to draw ui widgets, it uses libpr0n to render graphics in web pages. libpr0n runs on all platfors mozilla targets, gdk-pixbuf is a solution for gtk+ widget integration on X11.

    13. Re:Not exploitable in Firefox by TheAwfulTruth · · Score: 1

      Are these things loaded from downloaded "skins"?

      If so, we have our vector!

      There is always a way.

      --
      Contrary to popular belief, coding is not all free blow-jobs and beer. Those things cost MONEY!
    14. Re:Not exploitable in Firefox by hobo2k · · Score: 1

      libpr0n? serious? bwahahaha, open source is great!

    15. Re:Not exploitable in Firefox by TelJanin · · Score: 3, Informative

      Wow, libpr0n does exist. I thought it was just a joke.

  11. FC2 fixed already? by erroneus · · Score: 0, Troll

    I just ran UP2DATE yesterday on that pixbuf package. I think it would be too coincidental that it came out just before the announcement. I think FC2 already has the fix out maybe?

    Now if they'd get the new Mozilla package out there!

    1. Re:FC2 fixed already? by Compenguin · · Score: 2, Informative

      ldd searches for dynamic dependancies, hence no need for a new packages. Mozilla's gdk_pixbuf will be updated by the updated gdk_pixbuf containg package.

  12. Yeah, I was worried too... by spoco2 · · Score: 5, Funny

    Last time I ran "ldd firefox-bin | grep libgdk_pixbuf". I was pretty worried that I had no frigging idea what the hell I was typing.

    1. Re:Yeah, I was worried too... by nbert · · Score: 2, Informative
      Last time I ran "ldd firefox-bin | grep libgdk_pixbuf". I was pretty worried that I had no frigging idea what the hell I was typing.
      That pretty much sums up my feelings when I read it. But the first line of the man page says it all:
      ldd - print shared library dependencies
    2. Re:Yeah, I was worried too... by cyb97 · · Score: 4, Informative

      it's always uncool to run unknown commands that you've seen on slashdot ;-)

    3. Re:Yeah, I was worried too... by FooAtWFU · · Score: 4, Funny
      it's always uncool to run unknown commands that you've seen on slashdot ;-)


      Oh yeah? Well :(){ :|:& };: you too, buddy!

      --
      The World Wide Web is dying. Soon, we shall have only the Internet.
    4. Re:Yeah, I was worried too... by pclminion · · Score: 2, Informative
      :(){ :|:& };:

      Son of a BITCH, I was just about to post that! GAH!

      (Dear Slashdotters: The command shown above will not harm your computer, but will probably require a reboot to recover from it)

    5. Re:Yeah, I was worried too... by moonbender · · Score: 2, Interesting

      Wow. It nearly did, even running Cygwin on Windows XP. Weird stuff.

      I entered it in cmd.exe (ie the MS command line interpreter) and nothing happened, it didn't complain about a wrong filename or command, either. Then I entered bash and pasted it, and not much happened either, it indicated that a new background job was started. When I closed bash, though, the computer stalled, the SysInternals task manager crashed (ouch) and mouse movement went sluggish. After a while, an error message came up remarking that Windows was out of virtual memory. I think that's what stopped the command, because at that point the system was back to normal and there was a bunch of error messages in the terminal.

      --
      Switch back to Slashdot's D1 system.
    6. Re:Yeah, I was worried too... by nbert · · Score: 2, Interesting
      Since OSX switched to bash it's possible to run this command on it too - but it won't do much harm, since they limit the amount of processes per user by default. However, I don't know about the average linux distro, so YMMV...

      disclaimer: my box would crash if I'd enter :(){ :|:& };:

    7. Re:Yeah, I was worried too... by RyLaN · · Score: 1

      Oh yeah? Well :(){ :|:& };: you too, buddy!

      Alright, so we're all really funny. Now, would someone please explain to me why X died after I ran that as user in a shell?

      --
      At least the war on the environment is going well
    8. Re:Yeah, I was worried too... by Anonymous Coward · · Score: 1, Informative

      It's called a "fork bomb." Search for that term on Google, and you should get a better idea of what you shouldn't be pasting into your terminal. :>

    9. Re:Yeah, I was worried too... by Qzukk · · Score: 1

      in general, it defines a function called ":", which when executed, executes ":" and ":" and then backgrounds. Then it runs ":" and all hell breaks loose.

      --
      If I have been able to see further than others, it is because I bought a pair of binoculars.
    10. Re:Yeah, I was worried too... by Christopher_Wood · · Score: 1

      Your lack of knowledge is simple to fix. Read:

      man ldd
      man grep
      man bash (for the pipe - no, some people don't know)

    11. Re:Yeah, I was worried too... by pclminion · · Score: 3, Informative

      It makes more sense when you format it differently. It's a shell script (sorry to post as text, can't get the indentation to work otherwise):

      :()
      {
      :|: &
      }
      :

      Basically, it defines a function called ":" which, when executed, calls itself recursively twice and puts itself into the background. The last ":" actually executes the function. Thus, one shell forks into two shells, those two shells fork into four shells, those four into eight, etc etc etc.

    12. Re:Yeah, I was worried too... by runderwo · · Score: 1
      Because ulimit -u is set to way more processes than your box can handle, or that you would ever care to use.

    13. Re:Yeah, I was worried too... by Idarubicin · · Score: 1
      man bash (for the pipe - no, some people don't know)

      I'm pretty sure this is some sort of militant feminist code for 'go bash a man with a pipe'.

      --
      ~Idarubicin
    14. Re:Yeah, I was worried too... by argent · · Score: 1

      Like the "run microsoft" (rm) Windows emulator, with the "real fast" (-rf) options.

      [before you start rm-rf-ing, type man rm]

  13. Re:What are you going to do? Mod me -1, flamebait? by ScArE2100 · · Score: 3, Informative

    Now your GNU/Hippie software is vulnverable what are you going to do about it?!

    ...patch it before the vulnerability is even announced... not six months later.

  14. Yawn by ChiralSoftware · · Score: 3, Insightful
    Maybe Slashdot should have a separate section for this? As I've said again and again, we will keep having these types of vulnerabilities until we start using languages with safe pointers and safe memory operations. NX bits, library loading location randomization help too.

    I was just using the Icesoft Java web browser and the Fluendo media player. These are both big applications written in 100% pure Java. They both don't have buffer overflows because Java doesn't have buffers (in the C sense). How many security holes do we need to see every week?

    1. Re:Yawn by Bull999999 · · Score: 1

      How are the responsiveness of the Icesoft Java web browser and the Fluendo media player? I may get flamed for make this comment but I'm not too happy with the performance (speed wise) of Java application I've seen so far.

      --
      1f u c4n r34d th1s u r34lly n33d t0 g37 l41d
    2. Re:Yawn by Anonymous Coward · · Score: 2, Interesting

      Isn't there also the "D" programming language, which as far as I know, has many of the advantages of Java and C# (does not use unsafe pointers by default for instance) but has the advantage of producing proper compiled code.

      The experience I have of "trying" to use Java programs of any size (I don't think I've come on a .NET one) has so far been very painful. They keep telling me how it is so much faster now, and how computers being so much faster using an interpreted language is not that bad, but that's just NOT how it is. I keep trying to run those programs, with the lates JVM and I keep feeling the agony of it all.

      "D" on the other hand seems to be the natural evolution C/C++. It includes the nice features of the modern interpreted languages but compiles them into proper executables. It should definitely be considered by library writers (at least when it comes standard with gcc) as it would avoid a lot of these buffer problems.

    3. Re:Yawn by Anonymous Coward · · Score: 0

      No one uses that stuff because Java takes at least 10x longer to load and 5x more memory.

    4. Re:Yawn by Anonymous Coward · · Score: 0

      Mainly because the memory usage.
      Many of us still use 128 mbytes of ram or even less...
      I guess I would prefer using Haskell, as it's really compact (the language) and more easy to prove correctness

    5. Re:Yawn by LnxAddct · · Score: 3, Interesting

      The only slow programs in java are poorly implemented and use the Swing GUI toolkit in the wrong way. I personally like using Swing, and I use it efficiently, but in many cases the SWT toolkit by Eclipse will be jsut fine as well. SWT is a lighter, faster, toolkit that uses the native toolkit of the system. Java is extrememly fast, easily as fast as C++, if you need something faster then Java you should be using assembly. Read this. Also, the new JVMs by Sun have a feature called Hotspot, what this does is pretty much learn how your program works and adapts your program in real time to optimize it. What I mean is, the longer your program runs, the faster it gets because Hotspot learns what your program does more often and optimizes the bytecode in real time. You can not do this with native applications, itd be like rewriting the program on the fly without ever stopping it and having the effects take place instantly. This, along with no worries of buffer overflows, is a very good reason to use java. Java is a great language and any real coder knows that (just look at how many Apache projects are Java based), you'll only hear amateurs complain about java, just ignore them:)
      Regards,
      Steve

    6. Re:Yawn by Anonymous Coward · · Score: 0

      I dont know why people keep telling that Java is the cure for all "security" problems. Maybe they are trying to convince their selfs. Garbage collected && type safe && "insert your favourite feature here" languages exist since the 70's, and Java is the worst among those kind of languagues (take a look at Lisp/O'Caml). There is no automatic solution for security. The JVM *does* have security issues too!

    7. Re:Yawn by MichaelJ · · Score: 1

      Instead of a "safe" language, how about simply flagging the memory pages of the stack to be non-executable?

      --

      Michael J.
      Root, God, what is difference?
    8. Re:Yawn by argent · · Score: 2, Insightful

      The problem with Java isn't the speed of the runtime once it starts running, it's the huge bloody overhead as it cranks the JVM up. Of course you can use a shared JVM, if you want to abandon hard protection barriers between unrelated processes. It's fine in a webserver, but keep it away from my command line.

      There are safe languages with a lot less startup overhead than Java. Even quite slow languages like /bin/sh are better suited to a traditional UNIX environment.

    9. Re:Yawn by SillyNickName4me · · Score: 1

      Complaining about JAVA... first of all, take a peek here for some not so technical but still rather real problem.

      Then, it seems to me that hotspot on x86 machines mostly ends up generating 486, and in few ocations 586 optimized native code, and there are quite a few cases where that won't be that difficult to beat with modern compilers and good optimizing with any pre-compiled language (including JAVA of course). This is not a theoretical limitation on JAVA performance in any way, but it is one in practise on one of the most often used platforms.

      That said, I am happy with the performance of it esp. for serverside use, and my workstation is more then powerfull enough to not really notice startup delay of applications. I do not like its resource use, esp. when it comes to memory tho.

    10. Re:Yawn by Anonymous Coward · · Score: 1, Insightful

      Even 'safe' languages can produce exploitable code - aside from VM issues.

      Java's security record isn't that bright. Yes, in the hands of a poor or overworked programmer, it will produce less buffer overflows... but the VMs themselves have been vulnerable from time to time, etc.

      However, the -most serious- security issues are arguably the higher level ones, ie, with insecure protocols; they can be impossible to fix while retaining backwards compatibility.

      While Java fans like to hype the language as "the solution to everything", it's not. It's not 100% secure; merely 'better by default' than C and its ilk.

      Other alternatives such as ocaml or lisp or python have similar benefits; the former two can have speed pretty much on par with C, while the latter, interpreted at -run time-, has historically been similar to Java speedwise [according to Sun's own memos.]

      "Use Java!" is an easy mantra to repeat. In terms of pure security, it would be a benefit -over C-. However, multiple other languages exist that allow for both buffer overflow protection and speed; what Java has going for it is marketing, name recognition, more programmers who already "know" it to various degrees, and not much else.

      Yes, 'well-written' Java code can be fast. Well-written C can be secure. Problem is, there is a lot of code in both categories that just isn't either...

    11. Re:Yawn by Peaker · · Score: 1
      I know quite a few "real coders" who don't like Java, me included. Sure, its better than C or the hellish crap which is C++, but I prefer when my language has:

      Lexical Closures

      Dynamic Typing or Type Inference

      Nice syntax without noise

      And Java fails to have the first 2, with a syntax much more noisy and less concise than that of Python, for example.

    12. Re:Yawn by Bull999999 · · Score: 1

      Why don't they do what Mozilla for Windows does and come up with an option to pre-load itself to the memory during the start up process?

      --
      1f u c4n r34d th1s u r34lly n33d t0 g37 l41d
    13. Re:Yawn by ChiralSoftware · · Score: 1

      Java 5 has something somewhat like this. It has "precompiled" java.* classes which are ready to map into memory and run (ok, that's not a very precise description, but it's close). Apparently this has quite a good impact on start-up times. They are also working on memory footprint issues. It's true, Java is bulky but it is getting better. Actually it would be awesome if they could integrate it with the OS somehow so that the JVM is always running, and you don't need a separate JVM for each Java application. There was a project to do this called KaffeOS. I would like to see more things in this direction.

    14. Re:Yawn by Anonymous Coward · · Score: 0

      The problem with Java isn't the speed of the runtime once it starts running, it's the huge bloody overhead as it cranks the JVM up.

      Huh? Is that supposed to be a troll? The JVM is a program most likely written in C/C++ (chuckles) and loads very quickly. After that it's just the huge bloody overhead of Java..

    15. Re:Yawn by Anonymous Coward · · Score: 0

      As I've said again and again, we will keep having these types of vulnerabilities until we start using languages with safe pointers and safe memory operations.

      ... and then we'll just have different types of security vulnerabilities.

      The language is not the problem. As stated earlier in this very thread, only a poor workman blames his tools.

    16. Re:Yawn by IamTheRealMike · · Score: 1
      D is a lovely, beautiful language that never surprises me and does exactly what I mean - attributes I value highly in a language.

      Unfortunately it's also very new and rather immature. While a D frontend for gcc does exist it lags behind the official spec (which is itself incomplete). Also the D standard library is rather poor. It's not "safe" in the sense that Java is, because you can still use pointers but that is in turn its greatest strength : C interop is the easiest of any language. Easier than Java, easier than C#, maybe only Python with Pyrex comes close.

      Great, great language. I can't wait for it to mature.

    17. Re:Yawn by argent · · Score: 1

      Pre-loading and pre-initialising a JVM is fine for a single long-running application that you're likely to use during a session, or for a heavyweight daemon like Apache. For a command-line application that loads, runs to completion, and exits in a fraction of a second... you either have to abandon interprocess memory protection or have hundreds of preloaded JVM images start up on boot (one for root, one for operator, one for backup, one for mail, one for... multiplied by the number of command line applications you're using) and then again every time you log in.

      Even having a pre-initialised frozen JVM image for fast startup isn't enough for a UNIX environment. Consider an inetd- or tcpserver- based network service. Every network connection requires that startup, maybe multiple times. The applications I've written to run in this regime are typically a few kilobytes long, and in some cases less than a kilobyte: the application is small enough that a single disk read is enough to load it, small enough a dozen applications of this type can fit in the L3 cache on a modern CPU, let alone physical memory.

      Most command line applications are a few tens of kilobytes total. BIG ones are in the hundreds. When you don't have the overhead of a complex GUI built into the application the overhead of starting up even a frozen JVM can easily be an order of magnitude larger than the rest of the application put together.

      For an operating system without hardware memory protection this is fine: having one JVM and running all applications under that (ALL applications, mind you). Burroughs used a scheme like this in the A-series mainframes, and it worked well... but you need to design the whole operating system for it.

    18. Re:Yawn by argent · · Score: 1

      Unless the startup overhead can be reduced to a few thousand instructions, including I/O overhead, it's still going to be too high for UNIX script environments. For platforms like PalmOS where a single operation like Find can activate every application on the system in real time, you need to get it down to a few hundred instructions. The alternative of keeping every application activated concurrently is unreasonable when you consider that you can fit to fit a hundred or more apps into a device with 8M total RAM.

      There are fully interpreted environments with this low an overhead. Starting up a threaded interpreter, for example, can be done in half a dozen lines of assembly, and a threaded interpreter can be fast enough that it's competitive with compiled code... fast enough that it was practical to use on the fractional-MIPS systems of the '70s. Some provided a completely type-safe environment as well. The high overhead of the JVM is not required for a type-safe language, for an interpreted language, or an inherently secure language.

    19. Re:Yawn by tal197 · · Score: 1
      "Isn't there also the "D" programming language, which as far as I know, has many of the advantages of Java and C# (does not use unsafe pointers by default for instance) but has the advantage of producing proper compiled code."

      D makes it a lot easier to avoid unsafe code. It has garbage collection (no more double-frees), exceptions (no more failing to check return codes), inheritance (less dodgy casting), bounded arrays (including strings) to stop buffer overflows, etc. It also removes one of the nasty 'features' of C that makes static checking harder than it needs to be: the preprocessor.

      Unfortunately, very few people have a D compiler available, so anyone writing D code can expect lots of complaints from users who will have trouble compiling it.

  15. Security is always a problem.. by illusioned · · Score: 2, Insightful

    This is why I really hate when people start wars about one platform over another over security. No one is perfect, and errors like this will happen. The only real way to attempt to prevent flaws like this is more strict code reviews and more testing and debugging. Even those actions won't always find a problem like this because sometimes the problem is outside the bounds of the program's normal operation (ie invalid data in an image that wouldn't be found by testing with real images). All we can do is hope that there are more of us wearing white hats then there are those of us wearing black hats.

    1. Re:Security is always a problem.. by VoidWraith · · Score: 2, Funny

      And that the people without hats stop clicking on the damn things. "Ooh, more free porn"

    2. Re:Security is always a problem.. by argent · · Score: 2, Interesting

      This is why I really hate when people start wars about one platform over another over security. No one is perfect, and errors like this will happen.

      It's not the errors like this that bothers me about Windows.

      It's the design flaws that get exploited over and over again that are unique to Windows and they refuse to fix for political reasons. I mean, mail software that automatically executed scripts used to be a joke. We all knew that nobody would ever release a program like that, or if they did they'd remove that capability right away. The idea that someone would just keep patching specific instances of the general hole over and over again for seven years, well, if they did it on Star Trek you'd just laugh, it's like the super-intelligent AI that ran single-threaded... nobody would pull that kind of thing in real life!

    3. Re:Security is always a problem.. by Anonymous Coward · · Score: 0

      Some platforms are more secure than others. Agreed entirely that no platform is perfect; but some have far more design flaws than others.

      Assuming you're a competent admin who keeps up to date on patches, would you rather manage OpenBSD or Windows? MacOS or Windows? - leave aside issues such as "But... we need XYZ!" for the moment; I'm talking from an idealised security standpoint.

      Stricter code reviews and more testing/debugging can help, but they are -not- solutions, much less "the only real way." They can lead to more secure code; however, it's been known for decades that you cannot test all the bugs out of a product. Code reviews are exhausting and time-consuming; it's not practical to run them on every code base on Earth.

      Design also plays a role. I don't care how much you test telnet; you're not going to keep backwards compatability if you make it encrypted [see ssh.] Bog standard telnet is just as insecure as ever, despite good implementations.

      Security is more than an end-point that you patch and patch and patch software to. I recommend repeating this to yourself for a while.

      It's not true that "all we can do is hope $blah-about-hats". There are known things that can be done to make programs more or less secure. Don't use gets(); use fgets (properly). Don't printf(my_user_input_string) rather than printf("%s", my_user_input_string). If your app has a new protocol, -design- it rather than just going by "what seems to work". Consider using perl with taint mode, or basically any non-C/C++ language; bear in mind the costs of doing this as well as the gains. There are many, many, many little steps which can improve security; claiming there is only one or two is blatently wrong. Some environments have more flexibility than others; some are more secure by default than others.

  16. To head it off at the pass... by Dirtside · · Score: 5, Informative

    There's a particular comment which we'll see about a thousand times on this thread alone, the gist of which will be, "See? Even open source has bugs/security holes! It's no better than Microsoft!"

    The reason we bash Microsoft for its bugs and security holes is not because they have bugs and holes; the reason is that Microsoft paints itself as the savior of computing, as software that will make your life infallibly better and easier, and along the way has made quite a lot of unethical business decisions. They basically brag about how uber they are, and then they release crappy software and frequently take forever to fix certain bugs (or simply never fix them -- e.g. PNG transparency in IE. What's it at, 3 years and counting? 4?).

    The guys who write open source stuff like GdkPixBuf, on the other hand, have not (to my knowledge) done these things. They are thus not deserving of scorn; they write software, release it, and say, "I wrote this because I needed it. If you want to try it out, here you go. Have fun; I don't promise anything."

    That's why we mock Microsoft for its bugs and not the GDK team.

    (To be fair, I'm certain that there are some OS projects whose developers are as arrogant as Microsoft, but they at least do not have the unethical business history Microsoft does, nor do they (still!) have a monopoly on desktop OSes that they continue to abuse to the detriment of everyone except themselves. It's one thing to be an asshole when you're nobody important; it's quite another when you have a great deal of power.)

    --
    "Destroy science and religion. Science would re-emerge exactly the same; but not religion." - Penn Jillette, paraphrased
    1. Re:To head it off at the pass... by Anonymous Coward · · Score: 0

      But, to be fair, there are many who run around claiming that oss is inherently more secure than closed source software. While I agree it is silly to blame the developers themselves, I think it is valid to make the point that some oss advocates are wrong.

    2. Re:To head it off at the pass... by bob65 · · Score: 1
      There's a particular comment which we'll see about a thousand times on this thread alone, the gist of which will be, "See? Even open source has bugs/security holes! It's no better than Microsoft!"

      Um, actually I haven't seen it once in this thread yet. You sure this is the right thread?

    3. Re:To head it off at the pass... by LordP · · Score: 2, Informative
      I just wanted to point out that the lack of support for PNG Transparency in Internet Explorer is NOT a bug - according to the spec, it's optional...
      Viewers can support transparency control partially, or not at all.
      (Note: I'm not pro-Windows, I use Slackware on a daily basis, but I'm just tired of people claiming the above as a bug)
      --
      Nothing is so smiple that it can't be screwed up.
    4. Re:To head it off at the pass... by aardvarkjoe · · Score: 1

      In other words, the reason why everyone complains about Microsoft's software has nothing to do with Microsoft's software. Well, at least you're being honest.

      --

      How can we continue to believe in a just universe and freedom to eat crackers if we have no ale?
    5. Re:To head it off at the pass... by Dirtside · · Score: 1
      But, to be fair, there are many who run around claiming that oss is inherently more secure than closed source software. While I agree it is silly to blame the developers themselves, I think it is valid to make the point that some oss advocates are wrong.
      I would think that whether or not OSS development methods are inherently more secure (or stable, or featureful, or efficient, etc.) than closed development methods is a separate argument from whether Microsoft deserves extra scorn because of its attitude.

      I can't imagine that there are really that many people who claim that OSS produces software with no bugs, are there? Yes, I'm aware of the various rhetoric spewed by both sides, but claiming that OSS produces better software is reasonable. (Whether it's true is another story, but on the surface it's a reasonable thing to say.)

      I guess I'd want to be sure what it is you think OSS advocates are wrong about before I go off trying to prove you wrong (assuming that, once I know what you're talking about, I disagree with you), so let's start from there. ;)

      --
      "Destroy science and religion. Science would re-emerge exactly the same; but not religion." - Penn Jillette, paraphrased
    6. Re:To head it off at the pass... by Dirtside · · Score: 1

      My bad; I didn't know it wasn't part of the spec. Nonetheless, MS has in the past both spoken of its commitment to open web standards (and partly implementing them is not much of a commitment), and from what I've been able to find with a little Googling, MS stated sometime around 2000 that they intended to implement the full PNG spec, which they haven't. So even if it's not a bug, it's at least a broken promise.

      --
      "Destroy science and religion. Science would re-emerge exactly the same; but not religion." - Penn Jillette, paraphrased
    7. Re:To head it off at the pass... by Anonymous Coward · · Score: 0

      Claiming that OSS procedures can produce better code when it has not been demonstrated is not "reasonable", it's FUD.

      Physician, heal thy self.

    8. Re:To head it off at the pass... by Dirtside · · Score: 1
      You'll see that OSS makes the same claims too
      OSS isn't a monolithic group, like Microsoft. It's comprised of hundreds of thousands of separate developers working on tens of thousands of projects. Which of those developers are making this claim?
      1. To be the saviour of computing from Microsoft
      Which OSS projects have made this claim?
      2. Brag about how 'uber' they are
      Again, which OSS projects have made this claim? There are definitely OSS fanboys who like to trumpet OSS, but in my experience, the actual people writing OSS projects don't do this very much.

      At any rate, I said in my original post that there certainly were OSS developers who were arrogant, and why that arrogance was less scornworthy than Microsoft's. So I'm not sure what we're arguing about, since we basically said the same thing.

      --
      "Destroy science and religion. Science would re-emerge exactly the same; but not religion." - Penn Jillette, paraphrased
    9. Re:To head it off at the pass... by Dirtside · · Score: 1
      In other words, the reason why everyone complains about Microsoft's software has nothing to do with Microsoft's software. Well, at least you're being honest.
      What? I didn't say that. The scorn is the response to the combination of bad software practices, arrogance, and monopolistic abuse. There are certainly crappy OSS projects out there, although whether or not OSS produces better or worse software is an entirely different debate.
      --
      "Destroy science and religion. Science would re-emerge exactly the same; but not religion." - Penn Jillette, paraphrased
    10. Re:To head it off at the pass... by Dirtside · · Score: 1
      Yes, I'm aware of the various rhetoric spewed by both sides, but claiming that OSS produces better software is reasonable. (Whether it's true is another story, but on the surface it's a reasonable thing to say.)
      Emphasis added. I was saying that the OSS-is-better claim is not prima facie false, but it might be on further examination.

      Illiterate cowardly scum, train thyself to read.

      --
      "Destroy science and religion. Science would re-emerge exactly the same; but not religion." - Penn Jillette, paraphrased
    11. Re:To head it off at the pass... by aardvarkjoe · · Score: 1

      Oh, sorry. When you said "The reason we bash Microsoft for its bugs and security holes is not because they have bugs and holes; the reason is that Microsoft paints itself as the savior of computing, as software that will make your life infallibly better and easier, and along the way has made quite a lot of unethical business decisions," I thought you meant it.

      --

      How can we continue to believe in a just universe and freedom to eat crackers if we have no ale?
    12. Re:To head it off at the pass... by Anonymous Coward · · Score: 0

      To be fair, I'm certain that there are some OS projects whose developers are as arrogant as Microsoft

      *cough*RedHat*cough* ...oh wait, you said developers. i was thinking about management. Sorry my bad. I guess I'll have to go troll somewhere else.

    13. Re:To head it off at the pass... by Anonymous Coward · · Score: 0

      The reason we bash Microsoft for its bugs and security holes is not because they have bugs and holes; the reason is that Microsoft paints itself as the savior of computing

      Actually, no, it's because they are the world's biggest software company, and they release security fixes on a fortnightly basis for one of their flagship applications (Internet Explorer) that hasn't had any new development for three years.

      Mozilla, on the other hand, is a non-profit organisation that has a proactive stance towards security holes (by offering cash rewards to reporters) that has significantly less security issues in an application that is under constant development.

      PNG transparency in IE. What's it at, 3 years and counting? 4?

      Actually, PNG 1.0 was published in July 1996, so it's over eight years now.

    14. Re:To head it off at the pass... by dtfinch · · Score: 1

      About that png problem:

      http://homepage.ntlworld.com/bobosola/pngtestfixed .htm

      They've always been very very close to having it fixed. So close that it can be fixed more or less entirely with a small script tag at the bottom of your pages. It's simply laziness on their part.

    15. Re:To head it off at the pass... by Dryth · · Score: 1

      the reason is that Microsoft paints itself as the savior of computing, as software that will make your life infallibly better and easier, and along the way has made quite a lot of unethical business decisions.

      Watched a commercial lately?

      My knives utilize revolutionary cutting technology. My headphones contain patented technology that's bound to change audio as we know it. My toothpaste is recommended by four out of five dentists, and my car is the world's safest. Even my power bar provides the best in surge protection.

      At least, that's what the packaging claims.

      Microsoft sells a product. Over-selling can be bad, particularly if it breeds skepticism, or if it involves outright lies. However, you'll do better with hype than with "Windows: It's an operating system!"

      It's not just big companies either. My old restaurant claimed the best martinis in the city, and the local ice cream parlour makes the best in the country (ice cream, mind you, not martinis).

      If you think Microsoft's bad, watch more infomercials, or the Home Shopping Network.

    16. Re:To head it off at the pass... by 10101001+10101001 · · Score: 2, Informative

      Maybe an analogy would make it more clear? I don't scorn drug users. I scorn drug users who go around running over people because they're stoned while claiming they're perfectly okay to be doing drug.

      That is to say, I don't scorn all developers that produce software that has bugs. I scorn those who write software with bugs that gloat about how they write great, easy-to-use, etc software. Clearly, if their software didn't have bugs, there'd be nothing to scorn except their arrogance. If their software didn't actually have all the problems it does, they'd have a well-founded arrogance, and any scorn I'd feel would be jealousy. That's not the case.

      --
      Eurohacker European paranoia, gun rights, and h
    17. Re:To head it off at the pass... by Anonymous Coward · · Score: 0

      The reason we bash Microsoft for its bugs and security holes is not because they have bugs and holes;

      Uhhh, you obviously haven't been reading /. long.

    18. Re:To head it off at the pass... by aardvarkjoe · · Score: 1
      Your analogy doesn't work. The complaint about security vulnerabilities is that they hurt people. Thus, your analogy would make (a little) more sense by equating drug use with "arrogance" and running over people with software bugs. And then, of course, your argument kind of completely falls apart.

      And what the hell is up with the moderation the last few days? It's usually sycophantic, but lately it's been getting ridiculous.

      --

      How can we continue to believe in a just universe and freedom to eat crackers if we have no ale?
    19. Re:To head it off at the pass... by 10101001+10101001 · · Score: 1

      No, you're not lining up the right parts. The drug use is the development of software (whatever you like to do to feel good in your spare time). The running over people is the security vulnerabilities (which is bound to happen). And the arrogance is the arrogance of the drug user (can't get much more direct than that).

      So, the problem isn't the drug use. And it isn't even the running over people persay, though that's clearly a problem. But if a single person/company keeps running over people and acting like everything is okay, you start getting pissed off at them. I really don't know else to make it more clear.

      --
      Eurohacker European paranoia, gun rights, and h
    20. Re:To head it off at the pass... by aardvarkjoe · · Score: 1
      So, the problem isn't the drug use. And it isn't even the running over people persay, though that's clearly a problem.
      So what are you saying? "Yeah, sure, OSS runs over people just like Microsoft, but only Microsoft deserves criticism because they're more arrogant about it?" Maybe I didn't get your analogy because I couldn't believe that anyone would make such a bizarre statement.

      It sounds to me like you've already decided that you want to bash Microsoft, and now you're just fishing for excuses. And you're coming up with old boots.

      --

      How can we continue to believe in a just universe and freedom to eat crackers if we have no ale?
    21. Re:To head it off at the pass... by 10101001+10101001 · · Score: 1

      "Yeah, sure, OSS runs over people just like Microsoft, but only Microsoft deserves criticism because they're more arrogant about it?"

      Reword it to:

      "Yeah, sure, OSS runs over people just like Microsoft, but Microsoft deserves more criticism because they're more arrogant about it?"

      And you've got the point. And if Mozilla's developers start acting secretive or arrogant, I and others will start criticizing them more. That's how the world works. Of course, there's always going to be different degrees of "fan boys" who ignore the bad things a person/group does and still cheers long after most people feel they're deserving.

      As for fishing for excuses, like I was saying, it's the fact that Microsoft has had it occur so damn often while *still* acting like everything is a-okay that makes each new instance just another reenforcement of why I dislike Microsoft's attitude. More than anything, it tells me I can never really trust them when they say their software is good or secure. I most often trust the weary person more than the arrogant person because the weary person is probably closer to the truth. If you don't work that way, that's your thing. But please don't accuse me of "fishing for excuses".

      --
      Eurohacker European paranoia, gun rights, and h
  17. crowded theater by Doc+Ruby · · Score: 1

    We're not going to see the open source to a universal buffer object, with complete bounds checking, that every single buffer-requiring codepath calls, any time soon. So how about a "security watch" object that checks a specifiable URL for security announcements, which sends a message to a DB that notifies the sysadmin of security announcements, from warnings to patches? The DB could be set with alternate URLs, the watch object could require corroboration from multiple sources, the site policy could default to autoinstaling patches with certain signatures. Everyone talking about "white worms" that spread patches would want this infrastructure, which could be remotely administered under support contracts. Like a 21st Century fire alarm, calling a robot fire department.

    --

    --
    make install -not war

    1. Re:crowded theater by ScrewMaster · · Score: 1

      Which would probably work just fine as long as your fire department wasn't known as Microsoft.

      --
      The higher the technology, the sharper that two-edged sword.
    2. Re:crowded theater by Doc+Ruby · · Score: 1

      That's the idea: take the promise of Microsoft Update, and deliver it with a dependable, decentralized infrastructure plugged into the community. Even in NYC a century ago, when firefighters were private companies contracted by individual insurance companies to protect individual buildings, the landlords didn't own the fire companies, even though it was apparently in their best interest. That model eventually stabilized into the government organized volunteer force now cooperatively covering all buildings in the city, without any direct payments, although the system is subsidized by both the insurance business and the landlords.

      --

      --
      make install -not war

    3. Re:crowded theater by EnormousTooth · · Score: 1

      You mean like glsa-check?

      --
      I don't use Emacs; it uses me.
    4. Re:crowded theater by Anonymous Coward · · Score: 0

      Strings are essentially universal buffers (assuming they don't have a null-termination constraint, in which case there's usually a dedicated binary buffer object alternative), and so you have:

      FILE (C, granted not general purpose)
      std::string (C++)
      GString (GLib/GTK)
      numerous other library-specific buffer objects (I've written a few in my time)

      Writing a data structure that doesn't overflow is very, very simple, even without using Java or some other safe language. The problem isn't whether or not you can create such an object (it's quite easy to do, as I've just outlined), the problem is that programmers (who have already opted to use C, mind you) won't use them because they have some nebulous idea that using raw malloc()'d or array memory is somehow more efficient (it's not really that much more efficient, and for a number of operations, like certain kinds of concatenation operations, hand-coded is actually probably going to be slower, and they're definitely going to be faster than an interpreted language without JIT support).

    5. Re:crowded theater by Doc+Ruby · · Score: 1

      The data structure isn't the problem - it's the accessor methods, the operators, that have bugs. std::string is close, but what I'm talking about is subclasses of Buffer like FIFO, Stack, Heap, and a few others that include the bounds checking and other functions that ensure they don't deliver an executable payload to the processor. Even just renaming a string class to Buffer would let people subclass it and add safe accessors. It's not a hard programming problem. It's a hard programming culture problem. That's why we haven't seen the buffer overflows, the programming social disease, go away. So, to solve a cultural problem with a cultural construct, I suggest the even more robust autopatch network. Buffer overflows might thereby innoculate us against a host of other maladies, for a stronger, healthier platform in the long run.

      --

      --
      make install -not war

  18. It would be useful... by Quixote · · Score: 2, Interesting
    It would be useful if someone could post the sourcecode snippets, and show exactly how these vulnerabilities was caused. This is the advantage of OSS: you can dig into the sources and analyze them completely.

    --
    A neighborhood's tale

    1. Re:It would be useful... by Anonymous Coward · · Score: 0

      Then by all means, go ahead...

      Let us know what you find out.

      Wait, you don't want to? Can't? Well I guess you are as dependant on the OSS developers for help as Windows users are on Microsoft.

      Funny how the more things change, the more they stay the same!

    2. Re:It would be useful... by noselasd · · Score: 1

      Why would that be helpful except if you want to create an exploit ?
      Someone found the vunerabilites, someone fixed them. Good enough
      for me.

    3. Re:It would be useful... by mattpalmer1086 · · Score: 1

      Err... so you can learn how to protect code against these kinds of threat? Because you're interested in secure coding techniques?

    4. Re:It would be useful... by noselasd · · Score: 1

      There is no need for looking at code for that. It's all about
      beeing diciplined. _ALWAYS_ validate input(so you e.g. don't go past an
      array.)
      ALWAYS follow the API you use, and thing of all side effects, errors , etc. It can have (so you e.g. don't double free things).

  19. Re:What are you going to do? Mod me -1, flamebait? by VoidWraith · · Score: 0, Offtopic

    Damn Windows Zealots. Go back to your open areas and get out of our holes!

  20. Not Remotely Exploitable in Firefox by asa · · Score: 5, Informative

    Firefox doesn't use gdk-pixbuf for drawing it's images. The only places using gdk-pixbuf in Firefox are loading a couple of images from your hard drive into the browser UI -- like the little Windows desktop icon that shows up in the download manager UI. This isn't remotely exploitable in Firefox.

    --Asa

    1. Re:Not Remotely Exploitable in Firefox by henrik · · Score: 1

      And neither in Mozilla Suite I suppose?

    2. Re:Not Remotely Exploitable in Firefox by LiquidCoooled · · Score: 2, Interesting

      What if somebody uploaded a browser theme that had a craftily designed texture or image?

      Wouldn't that fall under the banner of exploitable?

      Are these theme files automatically associated for download with Firefox?

      Could somebody build a webpage offering downloads of these, or even get one onto the theme manager listing?

      All pretty far out, but at least possible.

      This is like finding out a nasty flu is going round. There is an exploit in something I use, I do not feel comfortable using it even though normal circumstances mean I am immune.

      I'll feel better once its cured :)

      --
      liqbase :: faster than paper
  21. Security by Anonymous Coward · · Score: 0, Troll

    Mac OS X > *

    1. Re:Security by Anonymous Coward · · Score: 0

      What was that 15+ vunerablity pack Apple just released a couple weeks ago then?

    2. Re:Security by 99BottlesOfBeerInMyF · · Score: 1

      Actually there have been 3 in the last week or so, which is pretty unusual for Apple. Of the many fixes included, however, I only see two that are remotely exploitable on a default install. One is a theoretical, this might be exploitable and the other is the new and very serious, links in ichat may remotely start programs, if the user clicks on them and the exploiter knows the path. I could see this used very maliciously with rm.

      Even so, I think practical security on OSX, while it could be better, is still on par with, or superior to most linux distros.

  22. Who do you mean by "we"? by Anonymous Coward · · Score: 0

    You certainly don't speak for me, schizo.

  23. Re:What are you going to do? Mod me -1, flamebait? by temojen · · Score: 3, Interesting
    ... vulnverable what are you going to do about it?!

    Fix it.

    You can't, thats why your going to...

    Actually, we can, that's one of the main reasons for the existance of open source.

  24. so much for linux being better... by Anonymous Coward · · Score: 0

    ...looks like linux suffers the same issues that MS OS's do, so lets hear how evil Linux is, and how it should be destroyed before it destroys the world!!!! ....or, we can all act like adults and face that no OS is perfect and all OS's are written by PEOPLE that do make mistakes!!!

  25. strace time by wurp · · Score: 1

    Sounds like time to strace Firefox and search for calls to gdk-pixbuf functions. I am on a shitty winders machine right now or I would do it myself.

    1. Re:strace time by Anonymous Coward · · Score: 0

      There have been several posts from Firefox's (and Mozilla's) developers, you just replied to one, and you don't believe them? They sure as heck ought to know when their code is calling gdkpixbuf code. I would be very worried if they didn't!

    2. Re:strace time by Lukey+Boy · · Score: 1

      Wouldn't it be easier just to download the source and search for it? strace can only show you functions as they're being executed, so it's coverage for any application of this size is way too small.

    3. Re:strace time by wurp · · Score: 1

      I think you're right, as a first try. However, it's quite possible that you would get caught up in "and this function calls that function which calls that other function which calls a forbidden function...", so it wouldn't be a simple search for forbidden functions but rather a search for forbidden, then a search for calls to the functions that call the forbidden, then searches for those functions, etc. strace keeps you from having to do that.

  26. Responsiveness by ChiralSoftware · · Score: 1
    Strangely enough, the media player is great, and Icesoft's browser is just ok. It seems like parts of the browser get swapped out and every once in a while it can take it a while to swap them in, or maybe that's the GC running. I don't know. Icesoft's browser is definitely not as smooth as Konqueror, for example. But then again, Konqueror is a much more mature product.

    I personally would rather have something a hair slower but a lot more secure. Also, if more desktop apps got ported to Java and Java got more real-world desktop use, the JVM would get tuned and adapted. There's no reason why it should be slow.

  27. Re:What are you going to do? Mod me -1, flamebait? by Anonymous Coward · · Score: 0

    Mod him to +5 Interesting and make him regret posting this as AC.

  28. Somebody is busy ...MSCE Revenge. by Anonymous Coward · · Score: 0

    "What we really need is a web page summarizing all the recent bugs in media decoding (mpg123 I think just had one) as a "how not to program" guide and then make it mandatory reading to get a sourceforge account."

    All those "paper certificate", "not doing it for the love" are getting their revenge. Maybe next time you "loving it" guys will be a little nicer.

  29. I was going to take your advice... by Anonymous Coward · · Score: 0

    But the new programing book I got, "Void *: If it works, it's done" recommended against it.

  30. Overflow testing by phorm · · Score: 2, Insightful

    How hard would it be to write a program that could be used to test apps against buffer overflow errors. This should be given the source of the app, where one could exclude various procedures (i.e. when the calling procecedure already tests for overflow).

    Difficult, impossible. Helpful or useless?

    I'd imagine that with such tools hackers could also test your code for overflows, but if it became mainstream to hardcore test for such things then perhaps they wouldn't have the opportunity.

    1. Re:Overflow testing by Anonymous Coward · · Score: 1, Informative
      Actually, such programs already exist. For example, valgrind does that and more:
      * Use of uninitialised memory
      * Reading/writing memory after it has been free'd
      * Reading/writing off the end of malloc'd blocks
      * Reading/writing inappropriate areas on the stack
      * Memory leaks -- where pointers to malloc'd blocks are lost forever
      * Passing of uninitialised and/or unaddressible memory to system calls
      * Mismatched use of malloc/new/new [] vs free/delete/delete []
      * Overlapping src and dst pointers in memcpy() and related functions
      * Some misuses of the POSIX pthreads API
    2. Re:Overflow testing by Anonymous Coward · · Score: 0

      Although it's pretty damn obvious that none of those were used until the Windows bug was found and someone went back to actually test their own stuff. SUPRISE!

      So now bugs in O.S. are only going to be found after they are discovered in Closed Source?!?!?

    3. Re:Overflow testing by jhoger · · Score: 5, Informative

      There is no algorithm to do what you are describing (google for "halting problem")

      You could run something like lint to catch common C errors.

      Better than that though is to profile your code actually running, to see buffer overflows and leaks that actually occur (google for valgrind).

      But most of these exploits are specially crafted input that produce buffer overflows. Typical input won't. So it is very hard to test for buffer overflows.

      The only 100% way to work these kinds of problems out is to write code in higher level languages, so at least you'll get an exception and fail closed in the case of a buffer overflow.

      But in C, the only way to resolve these problems is

      1) Don't write code with buffer overflows (hard)
      2) Find and fix buffer overflows in code review (harder)
      3) Write good enough negative test cases that you find the buffer overflows (really hard for even a good tester).

    4. Re:Overflow testing by Anonymous Coward · · Score: 0

      Actually, there is a way to catch buffer overflow for C/C++ programs. Valgrind intercepts the calls to the C library for malloc/new/free/delete so that it can track what memory has been allocated and when it is accessed. Because it knows how much memory is allocated it can see if a program accesses memory and then goes off the end (reading or writing).

      (I'm not affiliated in any way with the project, just trying to spread knowledge of a very useful tool.)

    5. Re:Overflow testing by bit01 · · Score: 1

      I'd emphasise another point:

      Don't trust the inputs.

      Inside a program is (in theory) a controlled environment. Whenever getting information from an unverified source (whether the environment, file, net, signals, pipes, semaphores etc.) verify the information is within the domain your program can handle and that you the programmer understand (e.g. URL lengths, file line length's, escape characters, environment PATH's etc.) and reject appropriately. Most cracks are due to crafted inputs. The program should be rejecting those crafted inputs as soon as they arrive. By concentrating on the inputs you drastically reduce the size of the problem you're dealing with and hopefully improve the reliability of the result.

      ---

      Patents restrict distribution by definition and are incompatible with standards which by definition promote distribution. Say no to patents in standards!

    6. Re:Overflow testing by Anonymous Coward · · Score: 0

      People can take this 'don't-trust-the-inputs' thing too far, though, where you have 5 layers of libraries all rigorously checking the input data, over and over again when it's really not necessary. I use a lot of ADTs (abstract data types) in my library design, so if any buffer overflows are going to be introduced, it's usually because of a bug somewhere else in my program. Checking the inputs usually doesn't do much to protect against a flaw in my internal coding, so I often don't bother checking for things like NULLs which will likely just crash the program anyway.

      I generally restrict most of my input checking to the highest level of programming. My application checks data rigorously to make sure it meets the standards of the function call involved, or better yet, I have a library function that will do the consistency checking before I feed in the input. Most of my applications are servers and utilities, so this boils down to checking data streams, which all use a fairly straightforward standard interface, and which I've already wrapped in safe calls, amortizing the buffer consistency check over bulk data transfers. From that point, the buffers are generally passed around as opaque data until their point of use (like a URI parsing function), at which point the data is parsed very carefully (this isn't quite as straightforward, however).

    7. Re:Overflow testing by tialaramex · · Score: 1

      You can write testcases, but this is equivalent to the task undertaken by your attackers, with the unfortunate distinction that you must find ALL the bugs, and they only need ONE that you missed.

      I've written testcases for N:M ratio software where many different applications make use of many different interoperable components (e.g. SANE's frontends and backends, or LADSPA's plugins and hosts). In this case it's important to preserve interop by detecting components that expect or provide something not agreed by the interface specification.

      It was quite common to write SANE scanner backends which only handled large, even-sized buffers properly. With most frontends (typically requesting 64 kbytes at a time) this works fine, and so the authors had considered their code to be of good quality. But network users (who request Ethernet packet sized buffers) had a lot of problems. These days the SANE testbed application includes a test routine to check for this and report it as a bug in the backend. Unlike the network frontend (which not everyone can really test) this test is built as part of the SDK, so no driver author has an excuse for not using it to QA their code.

      We never read about blackhats or greyhats who spent six months attacking a product with nothing to show for it, just like we never read about terrorists who survey a target and call off the operation because it's too well guarded. Only our failures get headlines :(

    8. Re:Overflow testing by Anonymous Coward · · Score: 0

      I'm sure you could write some heuristics to help determine potential invalid function calls and such, but in general I would think the problem is akin to the halting problem (determining whether or not an application will terminate given a certain input), which has been proven to be impossible to solve (in the general case).

    9. Re:Overflow testing by MarkByers · · Score: 1

      Just because a problem is hard or impossible to solve doesn't make it automatically equivalent to the halting problem. Even if they are equivalent, it doesn't mean that nothing can be done to help the situation. Consider this: It is impossible to write a program which determines if another program halts or not, but it IS possible to determine for some programs that they do halt. For example programs with no control flow statments (jumps) will always halt when they hit the last statement. In a similar fashion - some programs could be proven to not haven any buffer flows - for example if they do not contain any buffers at all, or else if all the buffer operations are performed via an interface which has been proved to be safe. We don't need to write a program that can check all valid C programs, just one that can determine that there are no buffer overflows in this restricted version of C. If some construct is used that is outside of the subset C this program can find, then it is unknown whether there are buffer overflows, but the programmer can be notified of this and modify their program so that it can be proved ot be safe. Now the question is, if it is worth confining ourselves in a subset of C just for security? Perhaps for some applications (top secret military work?) the answers is yes, but on the whole probably not. Alternatively as you pointed out, using a higher level language is a simpler/better solution for most of us. Regards, Mark.

      --
      I'll probably be modded down for this...
    10. Re:Overflow testing by jhoger · · Score: 1

      > Just because a problem is hard or impossible to solve doesn't make it automatically equivalent to the halting problem. Of course not, but proving correctness of a C program is the halting problem, and that is what was described. I was very careful to use the word "algorithm" as opposed to "solution." There may be a "good enough" solution. There is no algorithm.

  31. What the hell-UML by Anonymous Coward · · Score: 0

    Maybe we should start with the higher levels instead of cowboy programming?

  32. deja-vu by Performer+Guy · · Score: 0, Redundant

    I have a strange feeling of deja-vu, but something's different, almost like they've hacked the matrix, hmm... that's it! They've hacked reality to move a the vulnerability that was found in Windows only days ago.

    This is getting serious, somebody check the windows, quick!

    1. Re:deja-vu by Barlo_Mung_42 · · Score: 1

      I think you must be right. The windows vulnerability has been bricked up.

  33. feeding troll, but... by Anonymous Coward · · Score: 0

    Honestly, "safe" languages only help so much. JRE is enormous--do you really want to bet your security on the absence of exploitable overflows inside it? And there's more to exploitability than buffer overflows.

    I think a better tack is to _assume_ code will have exploitable vulnerabilities (obviously trying to avoid them, but acknowledging imperfection) and have the OS mitigate their impact. This is more or less the UNIX model. Large, multiuser systems, many of the users actively trying to mess things up (at universities, at least), and yet the thing keeps on ticking. I think SELinux, with its MACs, will bring us closer to this goal.

  34. Re:What are you going to do? Mod me -1, flamebait? by Anonymous Coward · · Score: 0

    ..patch it before the vulnerability is even announced... not six months later.

    In case you did not notice: it has been announced ... where is the fix?

  35. Amateurs my ass by HBI · · Score: 1

    On the desktop I don't want to put up with the load times of a VM and the fact that many applications are written to a particular VM, whether that be a particular point rev of Sun's JVM or Microsoft's. So much for write once, run anywhere. So how many JVMs do I have to put up with on my machine to realize this nirvana of no buffer overflows, exactly?

    In regards to being an amateur, I was in this business when you were in diapers, if your email address is any indication. Put simply, if I know the end user application is in Java and requires a VM I avoid it like the plague.

    I will well and truly laugh when an enterprising individual manages to successfully run arbitrary code inside a JVM again. Yes, it's happened before, and will happen again. Maybe it'll shut some of you amateurs who think that "because it's Java, it's secure" up.

    --
    HBI's Law: Frequency of calling others Nazis is directly correlated with the likelihood of the accuser being Communist.
    1. Re:Amateurs my ass by Anonymous Coward · · Score: 0

      Yeah, you are a lame ass amateur. Even a n00B right out of high school can write Java code in less time, with less bugs, and support more platforms than even the most experienced C coders.

      But, to write good Java code, that is efficient and use less memory, it is wise to have a strong C background first.

      Have you even seen the SWT? Have you seen Eclipse? I have yet to see another IDE with as much functionality, pluggability, and being adopted as fast as Eclipse. Think Rational, think WSAD. I'd love to see you write a C backed GUI that can run on ALL versions of Windows, Macintosh, and ALL versions of Unix. Yeah, old-timer, why dont you stick with your vi and e and become extinct like the rest of the dinosaurs as the world leaves you behind.

      In our development team we are always tracking down the memory leaks/core dumps/corrupted memory and stacks in the C code. How often do we have to do that in Java? never.

  36. Re:Poll Troll Toll by pclminion · · Score: 0, Offtopic
    I really hate you fucking Firefox zealots and your 'OMG MY BROUSER IS TEH BESTEST AND TEH MSOT SECURE!!!'-attitude.

    And I really hate fuckwits who generalize all people based on the stupid antics of a few people posting on Slashdot. Fuck off, and get thee back to kindergarten, dimwit.

  37. Re:I thought Linux was immune to this... by Anonymous Coward · · Score: 2, Insightful
    Though this isn't a kernel exploit, I thought one selling point of Linux was the "millions" of eyes on the code to prevent problems such as this in such highly re-used software as libraries. When MS announces these things, it's called crappy code; when Linux does this, it's simply "normal software life-cycle". Does nobody else see this as strange? I can't wait for the proverbial monkeys to start pounding away on all the upcoming Linux boxes and the inevitable number of bugs to be discovered.

    Hmm, guess I'll stick with MS since they've already gone through the monkey-pounding.

  38. Say what? by Anonymous Coward · · Score: 1, Funny

    I've never seen so much jibba-jabba in my life! What the hell is this story about? What's a bifpukfix and where can I get it? What needs updating? Jesus H. Christ in a handbasket! Can you say obfuscation?

  39. Re:What are you going to do? Mod me -1, flamebait? by ScArE2100 · · Score: 1

    There's no official patch yet, but the article notes several Linux vendors have issued updates.

  40. We don't need developers to brag, /. by Anonymous Coward · · Score: 0

    The Slashdot crowd already brags enough to be classiedfied as arrogant. They bassical brag about how uber they are, and if they release bad software or a bug is found they claim it will be fixed shortly... (unless your mozilla and you just don't publish the bug until you fix it, no matter how long you knew about it)

    1. Re:We don't need developers to brag, /. by Dirtside · · Score: 1
      The Slashdot crowd already brags enough to be classiedfied as arrogant. They bassical brag about how uber they are, and if they release bad software or a bug is found they claim it will be fixed shortly...
      What software has "the Slashdot crowd" released, exactly? I wasn't aware they were working on any collective projects.
      (unless your mozilla and you just don't publish the bug until you fix it, no matter how long you knew about it)
      All known Mozilla bugs are listed on Bugzilla, aren't they? It may not be quite the same as sending out a press release, but they don't appear to be trying to hide anything. At least, not as a systemic thing; I'd be surprised if NONE of the Mozilla developers had ever hidden ANYTHING from the public, but then I wouldn't claim that they hadn't.
      --
      "Destroy science and religion. Science would re-emerge exactly the same; but not religion." - Penn Jillette, paraphrased
    2. Re:We don't need developers to brag, /. by Anonymous Coward · · Score: 0

      Mozilla Bug Security Policy. Read it, educate yourself.

      Mozilla sits on security bugs frequently. They only have to mark it as a "private" and then they take as long as they want to fix it. The only time they fix it in a hurry is when it's made public. So, at any given time, there may be security bugs that moz devs know about and are hiding. That's called security by obscurity, and it's widely reviled when practiced by other companies.

    3. Re:We don't need developers to brag, /. by Anonymous Coward · · Score: 0

      That's called security by obscurity, and it's widely reviled when practiced by other companies.

      It's reviled because depending on obscurity is a bad idea long-term. But that's not what they're doing - according to the policy you link to, the point of keeping things secret is so that the exploit doesn't become public until a fix can be released.

      Afterall, if you were a black-hat, wouldn't you love to be able to trawl through bugzilla, looking for vulnerabilities that haven't been fixed yet? Given that bugzilla records would include all the details needed to exploit the vulnerability, it'd be irresponsible *not* to have a way of keeping things secret.

      That's not the same thing as keeping something permanently secret so that you don't have to fix it. *That* is what's reviled, for good reason.

  41. Re:I thought Linux was immune to this... by gnuman99 · · Score: 2, Insightful
    Though this isn't a kernel exploit, I thought one selling point of Linux was the "millions" of eyes on the code to prevent problems such as this in such highly re-used software as libraries.

    You seem to be missing the point. ALL software has bugs and those bugs need to be found the removed. That is the software cycle.

    I can't wait for the proverbial monkeys to start pounding away on all the upcoming Linux boxes and the inevitable number of bugs to be discovered.

    You know, I can't wait either because then these bugs will be fixed :)

    Hmm, guess I'll stick with MS since they've already gone through the monkey-pounding.

    Go for it.

  42. Re:I thought Linux was immune to this... by Anonymous Coward · · Score: 0

    MS == monkey-ponding?
    I'm not sure that sounds like a good thing.

  43. Executive Summary by Anonymous Coward · · Score: 0

    Even though "we" look like a bunch of stupid asses right now because of yesterday's flamefest, the most important thing is that we still hate Microsoft.

  44. Re:What are you going to do? Mod me -1, flamebait? by Anonymous Coward · · Score: 0

    Hmm. Interesting. If only I had a mod point.

  45. Tit for tat by Anonymous Coward · · Score: 0

    Looks like Redmond has UNIX types after all. It seems like every time a IE hole (jpg in this case) comes up about 3-4 days later they pick on open source.

    But do notice the severity... generally much less with open source.

    1. Re:Tit for tat by Anonymous Coward · · Score: 1, Insightful

      I would like you to meet Mr. Sendmail. And while you're at it, say hello to bind for me.

      Just be glad most serious *ix security flaws have been taken care of under less public circumstances before most /.'ers had ever heard of Unix.

  46. SuSE by karniv0re · · Score: 2, Informative
    gdk-pixbuf - Fixes for security problems in gdk-pixbuf

    This update fixes three vulnerabilites found in the XPM loader code of the GDK Pixbuf Library. They are registered as: CAN-2004-0782 Heap-based overflow in pixbuf_create_from_xpm CAN-2004-0783 Stack-based overflow in xpm_extract_color CAN-2004-0788 ico loader integer overflow.


    Thanks YaST!
  47. Breaks VMWare Workstation 4.x by mcrbids · · Score: 1

    I did a yum update the other day for my Fedora Core 1 laptop - and it downloaded a new gdk_pixbuf package that broke VMWare so that I couldn't get it to run.

    I'd guess this pixbuf is used to draw the widgets in XWindows. Here's a thread on this.

    I had to go through some contortions to get yum to retrograde my FC laptop and get VMWare (a show-stopper if not working) going.

    Since now there's a *new* vulnerability, I'm waiting until the dust settles and this is reasonably resolved before I try this again.

    First time I ever broke something with yum...

    --
    I have no problem with your religion until you decide it's reason to deprive others of the truth.
  48. Re:Poll Troll Toll by Anonymous Coward · · Score: 0

    yes it does.

    The Standard Buffer Overflow.
    The Standard Popup window.
    The Standard ActiveX Exploit.
    The Standard "Run any program and run any code" feature.
    The Standard malformed image exploit.

    Firefox etc are just starting to catch up.

    Image formats are getting a pasting at the moment. It will stop soon enough, the script kiddies will find something else to pick on.

  49. Firstly, by wurp · · Score: 1

    I had no way of knowing Asa is a Mozilla developer, secondly there are a lot of developers working on Mozilla and he wouldn't necessarily know if someone else put in a call to a verboten function. I am a developer and I can tell you on big projects often people use functions they shouldn't simply because it's impossible to keep everyone informed of everything they should or shouldn't do. Finally, it's really really easy to grep an strace for any of the functions declared in a library, so there's no reason not to do the test.

  50. you're gonna have to live with marketing... by Anonymous Coward · · Score: 0

    It's called selling product. Microsoft does it.

    I don't remember them saying anything as stupid as "we are uber", but they have said things to the effect of "we thing our software is worth buying".

    Microsoft makes no claims as to the fitness of their code for a particular purpose, have you not read the EULAs? They don't claim their software is the best thing ever.

    You let the open source people go because it suits your ends. Perhaps the writers of the buggy GDK tool here don't deserve scorn because they didn't make claims. But in that case, everyone who built on their software deserves scorn because they built on something which was done capriciously ("I don't promise anything").

  51. Re:I thought Linux was immune to this... by gordo3000 · · Score: 3, Interesting

    if you didn't realize by reading the news in the last week, it doesn't matter how long your software is attacked, new bugs are found. Yes, guess what, even microsoft has vulnerabilities announced every month. Millions of eyes on the code can help and obviously it did. We didn't hear about the new virus out there in order to find out about this exploit, we just found out about this exploit. Millions of eyes don't prevent mistakes, they do help find them faster and patch them quicker. And of course, even this story is exactly what that is, they already have vendors with patches out for this problem.

    hm..... seems Micrsoft, even with all its monkey-pounding, still doesn't have a shot in hell with fixing problems as fast as the open source community does. I'll stick with the box that doesn't stay vulnerable for as long.

  52. and write bullshit code that won't run everywhere by HBI · · Score: 1

    Unless someone installs a VM that monkeys with their browser configs, et cetera, to sit alongside the at least one other VM that is installed on any given machine. Great option.

    I'll buy that software!

    If your people are writing a lot of code with buffer overflows they are going to write crappy code in any language. End of story. If you and your coworkers can't be bothered to write solid code THAT IS NOT MY PROBLEM. I am NOT going back to the functional equivalent of a BASIC runtime module to coddle you. I wouldn't buy Visual Basic programs either, for that matter.

    Somehow I managed to write code that didn't have such vulnerabilities back in CP/M days and I still manage it.

    If you insist on using Java then compile it so I don't have to deal with crappy VMs. Then you might sell stuff.

    --
    HBI's Law: Frequency of calling others Nazis is directly correlated with the likelihood of the accuser being Communist.
  53. favicon.ico by lhaeh · · Score: 1

    Wouldn't favicon.ico be displayed as a gui elment? I know that icons rendered in geko are run through some sanity checks that made them safe from the recent jpeg/bmp vulnerability. It seems possable that something could get through since mozilla would use gdkpixbuf when rendering them.

    1. Re:favicon.ico by Anonymous Coward · · Score: 0

      Firefox uses GTK in a number of places for native look-and-feel, while Mozilla renders everything using X and its own toolkit (XUL, basically). Mozilla is thus entirely immune, and Firefox only uses the gdk-pixbuf for local icons (as has been mentioned a number of times here); favicons are probably all rendered using a common code path which is not vulnerable to this flaw, since it's also Mozilla-specific.

  54. Re:I thought Linux was immune to this... by Anonymous Coward · · Score: 0

    constantly claim that O.S. in fact does NOT have bugs.

    Bullshit. Not a single /.'er has ever claimed this. Parasite M$ marketing 'droid.

  55. But have you noticed ... by gstoddart · · Score: 1

    Yes. Software has bugs and it gets fixed.

    However, in the last week there have been three separate vulnerabilities related to parsing of images (IE, Moz, and now this).

    Not to be the one who looks for spooky coincidences, but might this belie a class of bugs in graphics software? Or is this kind of attack just becoming inevitable as (cr|h)ackers get more sophisticated?

    To me it just seems odd that this cluster of bugs in a particular niche of computing is showing as so vulnerable -- after all, every web browser is expected to trust graphics and just process them.

    --
    Lost at C:>. Found at C.
    1. Re:But have you noticed ... by geordie_loz · · Score: 1

      I think that the fact than MS anounced some image related flaws and exploits caused the open source community to go searching through their image code and see if similar bugs can be found.

      They did indeed find these bugs, so microsoft found it in theirs, o/s community responded to this.. This isn't to say that MS is bad for having the bug, and O/S is better, because they had these sorts of bugs too.

      The magic is in the fact that because open source is open the community was able to respond to this sort of thing, and act.. Closed source software is dependant on the vendor to fix this.. This is pretty much the whole reason for RMS to start his FSS stuff, because of some buggy printer driver I believe, he was quite prepared to fix it, for free, but the vendor was having none of it.

      The biggest issue open source people have with MS and proprietry software is that fact. Microsoft have shown so many times that they're unable to deal with the major issues, especially as some are more important to different parties. OS allows people with the ability to fix what's important to them. I'm sure if Windows and IE was open source (proper, not "shared source" crap) then there'd be a massive community of windows fans at the ready to plug those holes...

      Because Microsoft can't get their head around business models where the source is freely available, they can't see the benefit. A community contributed windows would result in a much better Corporate Image for Microsoft, and related stock stuff..

    2. Re:But have you noticed ... by gnuman99 · · Score: 1
      after all, every web browser is expected to trust graphics and just process them.

      No!!!!! :) I expect *every* browser to not trust *anything* it renders.

      This is the entire problem with software. Developers just assume that data X will come in Y format with the constraints of that format. Then you get security holes and exploits.

  56. Already updated by heathm · · Score: 1

    This is the cool thing about Linux. I just ran an update and installed a fix for this problem and now I'm reading about it on /. When has that ever happened for Windows?

  57. Let me add: "Well Duh!" by Ayanami+Rei · · Score: 3, Interesting

    As long as it's not a RAW screendump or uncompressed TIFF file or something, there's going to be some interpretation of the file's content to produce the human-consumable output. And it'll be based on a parameterized command stream. And if the interpretation of those parameters is not handled rigourously, or if the system does not account for every possible combination of commands, well then you're ripe for an exploit.

    That's basically EVERY file format.

    Even text can be dangerous. Ever heard of a terminal or ANSI bomb? (scroll down in link).

    The only "safe" viewer is a hex editor. Or less (maybe, you get the idea).

    --
    THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
    1. Re:Let me add: "Well Duh!" by maximilln · · Score: 1

      And it'll be based on a parameterized command stream. And if the interpretation of those parameters is not handled rigourously, or if the system does not account for every possible combination of commands, well then you're ripe for an exploit

      I get trolled heavily for saying the same thing and wondering why coders continue to write code which doesn't check the parameters at every iteration.

      --
      +++ATHZ 99:5:80
  58. Real issue is not "bounds-checking" by Ayanami+Rei · · Score: 1

    The real issue is these library programmers are serving two masters:

    1) Desktop use
    2) Embedded use.

    Generally they code for the latter, even if they know that the majority of use is going to be for the former.
    I've seen claims in libraries like libpng and zlib about how little memory required for decoding and such and such.

    Well guess what? It's all that grasping for allocating the smallest buffers possible that gets you into trouble. Because it's really easy to fuck up there. If you just play it safe and allocate as big a buffer as some atom of your file format is theoretically going to need to do what it does, then you wouldn't have to worry about stuff like that.

    And, it's like, so what! EVERY desktop operating system out there has a paged virtual memory system, and I guarantee if you don't use that extra unallocated memory in most cases, it won't "actually" get allocated. So the operating system (and thus the user) could care less, since it's demand-based anyway. But in the odd case that someone tries to fuck with you and actually use that memory, well you'll notice when your hard drive starts paging that somethings' up. :-)

    And not to disparage embedded developers: it could be as simple as adding a conditional compiler flag that uses the "safe" mode or the memory/pointer/fiddling version.

    libpng was already doing that with respect to feature support. Why not play fast and loose with memory in the full profile version?

    --
    THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
  59. For the widgets in the interface. by Ayanami+Rei · · Score: 1

    (Of course, so does every other program that uses GTK for the interface/widgets...)

    So unless someone has convinced you to download and use a GTK theme that has PNG files in it that exploit the vulnerability, you're okay. :-)

    --
    THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
  60. Check your expansions, ya Mac user! by Anonymous Coward · · Score: 0

    Mac OS X > *
    -> Mac OS X > Mac OS X
    -> 1 > 1

    That's the kind of reasoning that gets your home directory accidentally deleted.

  61. Someone's playing with image based attacks by Zarf · · Score: 1

    methinks someone has a new toy that lets them try out image based attacks. I expect this new toy will get a lot of excersize for a few months... no?

    --
    [signature]
  62. Such apps exist... by Goonie · · Score: 3, Informative
    I've seen applications that test command-line apps for buffer overflows. They work, and have been used to detect potentially exploitable bugs. The general principle can be used to test other types of apps, though obviously you have to adapt the program for each type of program input.

    A more general prevention method is to use an environment that doesn't allow buffer overflows; as Java proponents never tire of pointing out, Java guards against this type of attack. There are C libraries which do similar things, IIRC; StackGuard was one such method, though it seems to haved faded into obscurity.

    As to your suggestion of a static source code check for unsafe programming practices, there are programs that do that too. GCC itself includes a number of warnings that pop up if you use inherently unsafe C library functions, like gets() (which is buffer overflow in a can...).

    --

    Any sufficiently advanced technology is indistinguishable from a rigged demo
    --Andy Finkel (J. Klass?)
  63. It's often a bad idea by r6144 · · Score: 2, Interesting
    1. I guess no library that need any security now has much code containing arbitrarily-sized arrays like "char x[256]" now (unless specified in some standard). Most arrays have a well-defined size that possibly depends on the input, allocating an extra 1024 bytes will not save you if the array should have a size of DSIZE+SSIZE instead of 2*DSIZE, where DSIZE and SSIZE depends on the input, or if the 32-bit array index from the input data is not properly bounds-checked. What's more, the extra size would confuse maintainers as of how much space is really needed.
    2. Even if you use Java or other "safe" languages, such a vulnerability will still result in an array-out-of-bounds exception (hopefully properly handled) in the best case, and it won't be long before you get an OutOfMemoryException or an infinite loop or even worse.
    3. I guess taint checking would be useful here, whatever the language is.
    1. Re:It's often a bad idea by be-fan · · Score: 1

      With regards to #2, an uncaught out-of-bounds exception (resulting in a *controlled* applicaton crash) is a hell of a lot better than somebody inserting arbitrary code into your app. An app that crashes all the time because of out-of-bounds errors still sucks, but at least it isn't a security hole.

      --
      A deep unwavering belief is a sure sign you're missing something...
  64. I love my disro ;) by Anonymous Coward · · Score: 1, Informative

    I just woke up, red this, and checked the SuSe update.
    And guess what, the patch was allready there.

    Gotta love the OSS usually-same-day-patch-cycle.

    Thumbs up, SuSe!

  65. Very similar by FullCircle · · Score: 3, Interesting

    Isn't it a bit odd that these libraries are failing on both Windows and Linux?

    I wonder of someone has been stealing source code?

    --
    If tyranny and oppression come to this land, it will be in the guise of fighting a foreign enemy. - James Madison
  66. great by bmzf · · Score: 1

    Thanks for the update. Now on my Fedora setup, all the image thumbnails in Nautilus look like they were side-swiped by a bulldozer.

  67. Hooray for C and C++ by Laxitive · · Score: 1, Insightful

    Hey, I have a great idea!

    Let's keep writing software in an unsafe, glorified assembly language (and glorified assembly languages with OBJECTS!). You know, because it's not like we care about safe applications or anything. We need our button widgets to complete their draw operations in under 5 microseconds.

    Seriously, we don't need to check array dereferences. It takes up AN ENTIRE WHOLE INSTRUCTION for each dereference. That's insane, we might have to wait a whole millisecond for a button widget to redraw. And how can we deal with that? I mean, remote code getting executed on my local machine every once in a while, I can understand.. but I want my user interface to be SNAPPY.

    And besides, only stupid programmers write programs that can't deal with unsafe memory access. I mean, how stupid do you have to be? It's very easy: only clobber memory that needs to be clobbered. It's not rocket science!

    No, we don't need garbage collection, either. Real men keep track of all their pointers, all over their programs, and use ad-hoc reference counting schemes if necessary!

    Yep, hooray for C and C++.

    -Laxitive

    1. Re:Hooray for C and C++ by Anonymous Coward · · Score: 1, Insightful

      So what do you write your uber language in? C? Well, better make sure that you debug that correctly, then, or you'll just have the error somewhere else...

    2. Re:Hooray for C and C++ by chro57 · · Score: 0

      As you seem to be very intelligent, clever, and good willing, and seem to have a lot of experience dealing with the writing of OS, GUI, and generally big software that are used by millions of persons, you shall stop ranting about the use of higher level language (HLL) and actually demonstrate their power by actually writing cool software using it. I am waiting for you ueber LISP or Java Operating System. Or perhaps Perl :-) Or perhaps you should evangelize MS into doing full C#. Then you may discover that security pbs does not consist just into checking null pointers, and that you can still write insecure software using very HLL. I also wait for maximum performance and security of your magic compiler translating very complex HLL algorithms into efficient MMX-Altivec- asembly langyuage, and automagic correct management of interlangugage linking. Hint : these pbs have very complex theorical developments, including checking of complex properties of complex programs written using complex language. Program carrying proof, model checking, temporal logic... Bad programs can be written in any language.

    3. Re:Hooray for C and C++ by BenjyD · · Score: 1

      Why switch languages? Checked memory access is easily implementable in C/C++. I'd post a quick example but the lameness filter is too annoying.

  68. Security through diversity ... by Gopal.V · · Score: 2, Insightful
    I compile a LOT of my libraries on my box (it's an FC1 hybrid) and my other box is a gentoo.

    Most of the exploits (ie actual "exploits") depend on the EIP or some other register being clobbered or the stack being smashed to execute a data block. Metasploit has a nice database of such clobberable locations for Windows

    So if you compile your own stuff with your own "-O3 -fomit-frame-pointer -fstack-protector", you may be breaking the binary compatibility of exploit :). Most ordinary exploits will fail for such custom compiled stuff , unless the guy at the other end takes a memory dump (hard to do undetected over the network) and reads the .stab entries first to figure out your box's weak spot (to use "-g" or not ... hmm..). If you're dealing with guys like that , then you'd better invest a bit better in security than I do . I call it "Security through Diversity" .

    Too bad windows users don't have that option.

  69. Fedora by Anonymous Coward · · Score: 0

    Updated this one yesterday on my Fedora Core 1-machine.

    Thanks up2date! :)

  70. Java is a bad example by jeif1k · · Score: 1

    Java is a bad example of a safe language, because, while it is safe, it also has a lot of other baggage that you really don't need, and because Java keeps you from doing unsafe things even when you ask nicely.

    A safe systems programming language does not need to be noticeably different from C in terms of performance or programming style. Furthermore, a safe systems programming language shouldn't prevent you from doing unsafe things, it should just force you to make it explicit when you are doing unsafe things.

    There are currently no safe systems programming languages that would appeal to a hardcore C user (D, Cyclone, and similar efforts are trying to do too much). But in the past, there have been some pretty straightforward Pascal and Modula dialects that combined being fairly simple with being efficient and suitable for systems programming. So, it is possible, someone just needs to do it in the C family of languages.

  71. MOD PARENT UP! by Anonymous Coward · · Score: 0

    yeah

  72. Formal verification by Sits · · Score: 1

    It is possible using certain languages to formally verify and basically prove that for a certain program a particular set of properties does or does not hold true. I am fairly certain it is not possible to do this with a non trivial program in C (unless you try and annotate it and/or restrict which operations you are allowed to do) though, so this point is a bit moot.

  73. Right, right... by warrax_666 · · Score: 1
    Even if you use Java or other "safe" languages, such a vulnerability will still result in an array-out-of-bounds exception (hopefully properly handled) in the best case, and it won't be long before you get an OutOfMemoryException or an infinite loop or even worse.


    There is a big difference between a DoS (which programs in "safe" languages may be open to) and an actual exploit -- which is basically a privilege escalation from "I can ping you" (or even less, actually, with these "passive" exploits that are becoming more and more popular) to "I can install a keylogger". Big. Difference.
    --
    HAND.
  74. Re:What are you going to do? Mod me -1, flamebait? by Anonymous Coward · · Score: 0

    I would be willing to bet that 90% of the Slashdotters who say, "'We' can fix it!", can't code their way out of a do loop and have never contributed to any project.

  75. Good advice, but... by mattpalmer1086 · · Score: 1

    ...the truth is that secure coding is a lot more complex than that.

    There are common functions which can be insecure if used in particular ways. There are different kinds of buffer overflow attack - e.g stack and heap attacks. Sometimes the API you are correctly using is itself the problem in that context. Sometimes the particular kind of data you're dealing with requires different forms of validation.

    So in the real world it's very useful to be able to examine insecure code and the resolution to the problem.

  76. Remiss by adalberto_kapiloff · · Score: 0

    ref hugi lay ju
    tah luxe xujaw wi be
    wir deco xip ne

  77. Re:I thought Linux was immune to this... by Anonymous Coward · · Score: 0


    constantly claim that O.S. in fact does NOT have bugs.

    Bullshit. Not a single /.'er has ever claimed this.

    That's the message that /.'ers send when they fault Microsoft for having bugs in their code. You can try and spin it anyway you like but that's the message they're sending.


    Parasite M$ marketing 'droid

    Is this the best rebuttle you could muster?

  78. Not at all similar by FreeUser · · Score: 2, Insightful

    Isn't it a bit odd that these libraries are failing on both Windows and Linux?

    I wonder of someone has been stealing source code?


    While it is possible Microsoft may have violated the licenses of open source and free software projects, it is doubtful. It is virtually certain that the opposite is not the case, unless Microsoft lackeys are deliberately trying to poison the well, in which case a court would find the Microsoft willfully released the code into the wild, effectively licensing it. That isn't very likely either.

    What we do know is that C and C++ have vulnerabilities in how the language is used with respect to buffers, that can get even experienced programmers into trouble. We also know that algorithms for reading and drawing images are widely known, widely published, and quite standard, so any two (or more implimentations) are likely to run afoul of similiar mistakes in programming and weaknesses in the language (C/C++) used.

    Why moderators find it "insightful" or "interesting" to make the extremely unlikely insinuation that someone is probably be violating copyright in order for similar issues to arise out of code doing similar tasks using similar programming languages and similar libraries, accessing similar open standard graphical formats, bespeaks an agenda and ax to grind (either against Microsoft or Free Software), not an understanding of the underlying coding issues.

    I loathe and despise Microsoft as much as anyone, and for good reason, but lets try to limit our lambasting of that destructive and dangerous entity to issues which have a grounding in fact, and not unlikely scenerios like this. There are a plethora of real, documented activities by that company that can provide more than enough fodder for criticism, without insinuating the very unlikely in defiance of occams razer and all real sense.

    And if the jab was meant for Free Software, then replace the word "unlikely" above with "absurd beyond any rational measure."

    --
    The Future of Human Evolution: Autonomy
  79. Re:What are you going to do? Mod me -1, flamebait? by Anonymous Coward · · Score: 0

    on the other hand, what % of windows users would you say could program?

    of that %, what % of them have access to the code to even attempt to try to fix it? of THAT fraction, what % of them would be able to submit the code to MS to make a patch with?

    at least we have 10%* of linux users that can fix it. i would guess 50% of windows users don't know how to right click, but thats based on calls while working in tech support. no one calls tech support when they know what they are doing.

    i guess it boils down to: is 10% of linux users a bigger number then the total staff at MS?

    * assuming your guess is as bad as mine.
    ** no actual statistics were used in the writing of this post.

  80. "how not to program" by Trepidity · · Score: 1

    Don't use C, C++, or other languages that permit buffer overflows, because chances are if you do, your code actually will have buffer overflows. Even if you audit it.

    1. Re:"how not to program" by Anonymous Coward · · Score: 0

      When I code in C, I'm damn well careful about buffer sizes and array bounds.

      When I code in Java, I'm careless about it because I know that the JVM will just throw exceptions.

      Result? My Java code is usually buggier than my C.

      It's not like a Java program can't have security problems anyway... It will just have the subtler, logic based problems.

      Your statement is rather like "don't use a hammer because you can hurt yourself with it."

  81. that's not the issue by Trepidity · · Score: 1

    The issue is that C is very difficult to properly code, because it does not give compile errors for buffer overflows. Indeed, it is almost never coded without buffer overruns, even in security-critical software (like OpenSSH).

    I really have no idea why people wouldn't use Ocaml, or Ada, or Haskell, or Java, or whatever the hell they want that isn't C. Parent poster is right: this isn't 1978 anymore.

    1. Re:that's not the issue by 2forshow · · Score: 1

      C may be AN issue but coding is still another issue that will never be overcome. No matter how secure you think you can design it some genius kid will come along and crack your code. Look at DVD encoding. The people who developed the algorithms (and it may have been written in C) thought they were so secure that the first DVD's to come out did't even have the FBI warning on them because the developers thought no one could crack it. But then some unknown (at the time) kid came along and cracked it. He saw something the programmers couldn't see because they were the ones programming. It's just like writting a paper, you may have read it a million times and think it is grammtically perfect, but when your friend reads it he points out errors you couldn't see because you were the one to write it. Again programming in C may be one issue but there are many other that are just as if not more critical.

      --
      Free Ipods it's for real check out Wired then go to: http://www.freeiPods.com/default.aspx?referer=8533
  82. probably in the language itself by Trepidity · · Score: 1

    Historical bootstrapping may vary, but most high-level languages these days are written in themselves, and compiled using a previous iteration of the compiler. Lisp compilers written in Lisp; ML compilers written in ML; etc.

  83. not really by Trepidity · · Score: 1

    It's more like "don't code in C, because every time you bastards do, it ends up with a buffer overflow." OpenSSH, libpng, gdkpixbuf, the list goes on for quite some time.

  84. It is natural QA function. by nortcele · · Score: 1
    I just wish people with that much determination would concentrate on fixing the bugs, instead of exploiting them ... so much wasted talent.

    Agreed.
    These guys are just performing a vital Quality Assurance function that any normal company has. When is the last time you received an email from your local QA Dept that also included a fix? Only messages I have ever seen are like... "This part fails every test we throw at it. It is crap." Then marketing reduces the specs and sells it anyway. Thank heavens that in Open Source there is no marketing (yet). Sales and Marketing are just spammers with real jobs.

    Whew! That makes me feel a lot better.

  85. No by Anonymous Coward · · Score: 0
    No, the startup time on Java 5 is going to be a lot more than a few thousand instructions, and it almost certainly will be too high for UNIX script environments. UNIX script environments are pretty unique in that the same program gets fork()ed a million times a second (or whatever). Java just isn't suitable for that. The Java answer is to do the whole thing within one JVM session. I know that answer doesn't work in all cases, but that's the way it's intended to be used. Compare ant vs. make. Make forks off a compile process for every file that it compiles. Ant never forks anything. The compiler just executes within the same JVM that Ant is running in. As a consequence, ant is very very fast. But if it had to fork a compile process for every file, it would be much slower.

    But you're right, the JVM just isn't good for UNIX script use, and UNIX scripts are wonderful things for their intended purpose. Different tools for different tasks I guess.