Slashdot Mirror


Image Handling Flaw Puts Windows At Risk

An anonymous reader writes "Microsoft has released word that several image handling flaws may open Windows PCs to Spyware or viruses. From the article: 'We will continue to see this type of vulnerabilities in every major application for the foreseeable future ... It is not just images, but any type of complex file format. This is something that security researchers and hackers have realized to be a weak point in many applications.'"

287 comments

  1. Huh? by Anonymous Coward · · Score: 5, Funny

    Windows wasn't open to spyware and viruses before?

    1. Re:Huh? by zonker · · Score: 0

      yeah, didn't this one get ya off guard? yawn...

      making fun of windows is like kicking special olympics winners in the face. sure's it's fun for a while but it's just too damn easy.

    2. Re:Huh? by Anonymous Coward · · Score: 0

      That was patched for yesterday,11/08/2005, in Windows 2000/XP/2003:

      Filename - WindowsServer2003-KB896424-x86-ENU.exe

      MS05-053 - Vulnerabilities in Graphics Rendering Engine Could Allow Code Execution (896424)

      http://www.microsoft.com/technet/security/bulletin /ms05-nov.mspx

      * :)

      APK

      P.S.=> On this one, the "Anti-Microsoft" crew here @ slashdot are just (once again) a day late & a dollar short is all I can say here... I just can't give the "antimicrosoft" penguins this opportunity to spread yet MORE "F.U.D." b.s. around... apk

  2. DUPE by 42Penguins · · Score: 4, Funny

    This vulnerability is a dupe!
    Windows has already had an image handling flaw!
    Oh, it's Windows. False alarm.

    1. Re:DUPE by Anonymous Coward · · Score: 2, Informative

      So a lot like Firefox. Multiple GIF and JPEG arbitrary code execution vulnerabities found to date, though only one PNG arbitrary code vulernability (best vegas odds for the next FireFox image vulnerability?). OS X has to pick up the slack when it comes to some of the more obscure formats, having suffered execution vulnerabilities in oddball stuff like PICT.

    2. Re:DUPE by eln · · Score: 2, Informative

      Times like this, you wish /. would use some other format for the posting date. Maybe one with the year in, for example. Sheesh.

      If only there was some place that you could configure how posting dates are displayed. Perhaps in your user preferences somewhere...

  3. Critical Bug? by geomon · · Score: 5, Insightful

    Okay, so it is critical. The advisory contains the patch to correct the problem. This only becomes an issue if Windows users don't patch their machines.

    What is the likelihood that users won't patch their machines? (cough!)

    From TFA:

    Mehta doesn't expect the latest Windows flaws to be exploited in a widespread attack. "We're not bracing for any major worm or malware outbreak, but we do expect them to be used in targeted attacks," Mehta said. "There is user interaction required, there has to be someone sitting at the other end in order to be compromised."

    Yeah, like viewing an image from usenet. No one ever does that.

    --
    "Rocky Rococo, at your cervix!"
    1. Re:Critical Bug? by Marxist+Hacker+42 · · Score: 2, Informative

      Not just any image- a MetaFile. Other than when I'm on a Windows Machine using the Clipboard, I stay away from those suckers. They can, and do, contain just about anything.

      --
      SJW: a person who perceives an injustice, and while correcting it, commits a greater injustice.
    2. Re:Critical Bug? by ninja_assault_kitten · · Score: 2, Insightful

      No, it also becomes a problem when/if the patch breaks something else, like it did with one of last months security fixes.

    3. Re:Critical Bug? by geomon · · Score: 1, Funny

      No, it also becomes a problem when/if the patch breaks something else, like it did with one of last months security fixes.

      Windows programs NEVER break applica.,M0$2;mfwe-23487.we

      --
      "Rocky Rococo, at your cervix!"
    4. Re:Critical Bug? by Anonymous Coward · · Score: 1, Interesting

      Yeah, like viewing an image from usenet. No one ever does that.

      Somehow I detect sarcasm here, but it's actually quite true without it.

    5. Re:Critical Bug? by Anonymous Coward · · Score: 1, Funny

      So usenet is dead?

    6. Re:Critical Bug? by geomon · · Score: 2, Funny

      So usenet is dead?

      Netcraft confirms it!

      --
      "Rocky Rococo, at your cervix!"
    7. Re:Critical Bug? by conJunk · · Score: 4, Funny
      What is the likelihood that users won't patch their machines?

      Well, it went up on the slashdot mainpage, so that likelihood for a great number of users is a lot lower than it would have been.

      The 35 users I'm responsible for just got an email instructing them on how to to do the patch, with links to the patch execs that now live on our local file server.

      This model -- (1) Microsoft announces it; (2) I hear about it on /. or security focus (usually both); (3) my users hear about it from me -- works well.

      Sure, that's a drop in the bucket for windows PCs, but the point is that the communication chanels are open, and as long as people have the oportunity to hear about these things, we can reasonably expect them to be responsible for implementing them

      Of course, that's not an excuse for making vulnerable software in the first place...

    8. Re:Critical Bug? by shmlco · · Score: 3, Informative

      Of course, we also have recent announcements of imaging bugs and vulnerabilities in Apple's QuickTime that can allow machines to be hijacked. As such, I gather *nix systems can and do have similar problems.

      --
      Any sect, cult, or religion will legislate its creed into law if it acquires the political power to do so.
    9. Re:Critical Bug? by ozmanjusri · · Score: 4, Funny

      So usenet is dead?

      alt.binaries.necrophilia has been very quiet lately.

      --
      "I've got more toys than Teruhisa Kitahara."
    10. Re:Critical Bug? by geomon · · Score: 2, Informative

      As such, I gather *nix systems can and do have similar problems.

      The volume is different, to be sure. That is probably an artifact of the number of users running the OS.

      But your point is well taken; no operating system is immune to attack. Unfortunately, Windows users generally lack the discipline to patch their machines regularly. I don't know many *nix system users who do not perform regular updates.

      That probably accounts for the low infection rates of *nix-related system.

      --
      "Rocky Rococo, at your cervix!"
    11. Re:Critical Bug? by mspohr · · Score: 1, Troll
      I just went to microsoft.com to patch this bug. It started hassling me with it's "Genuine Microsoft" initiative and it wanted me to enable ActiveX and load some special software to check if I had a legitimate version of Windows (I do... this is a Dell laptop with factory installed WindowsXP).

      I don't trust Microsoft, I don't trust ActiveX. I didn't get the patch... time to switch to Linux...

      --
      I don't read your sig. Why are you reading mine?
    12. Re:Critical Bug? by Anonymous Coward · · Score: 0

      The check was bypassed long ago.

      In summary:

      Before pressing 'Custom' or 'Express' buttons paste this text to the address bar and press enter:
      javascript:void(window.g_sDisableWGACheck='all')

      or

      Tools -> Manage Add-Ins -> Windows Genuine Advantage -> Disable

    13. Re:Critical Bug? by jerw134 · · Score: 1

      Why aren't you using something like Active Directory/WSUS to automate the patching?

    14. Re:Critical Bug? by drsmithy · · Score: 2, Funny
      I don't trust Microsoft [...]

      Then why would you try to install the patch in the first place ? Heck, why would you even be running Windows ?

    15. Re:Critical Bug? by ZhuLien · · Score: 0, Flamebait

      The problem is that unforunately I have to use Windows, but I don't trust Microsoft so no way am I going to use their patches.

    16. Re:Critical Bug? by Steeltoe · · Score: 1

      But your point is well taken; no operating system is immune to attack.

      I would guess OpenBSD is pretty much immune to this type of attack, as long as the OS is not borrowing binaries from other OSes, but instead compiling it with propolice stack protection, and all the other nifties in 3.8. It will still crash of course, given that the bug remains in the package, but it will be near impossible to exploit it.

      I would love to see an easy install/upgrade path for OpenBSD. As it is now, there's too much politics and too little hand-holding for me to accept it. I can probably figure it out, but time is an issue, and others can't reasonably take over when the bar is so high compared to Ubuntu / Debian.

      What is surprising to me is how little Linux people value security. You would think the necessary means would be put in place, but only fringe distros like Adamantix really do it.

    17. Re:Critical Bug? by Taladar · · Score: 2, Interesting

      Aren't you putting users at risk when telling them to patch in an Email? After all there are lots of scams with that theme (big vulnerability, patch here, patch is trojan).

    18. Re:Critical Bug? by Viol8 · · Score: 1

      Most linux users arnt stupid enough to run as root so most viruses
      trojans etc would have limited impact. Most windows users however
      *do* run as root/admin so once inside the OS the trojan can do what
      it pleases.

    19. Re:Critical Bug? by nitz7978 · · Score: 0

      ever try WSUS for patch delivery? its been working great on all my servers and desktops for the last 3 months. just a thought.

    20. Re:Critical Bug? by Indiana+Joe · · Score: 1

      OK, how many of you just looked to see for yourself?

      --
      I can't decide if this post is interesting, funny, insightful, or flamebait.
    21. Re:Critical Bug? by Just+Some+Guy · · Score: 1

      And you know this because...?

      --
      Dewey, what part of this looks like authorities should be involved?
    22. Re:Critical Bug? by Lord+Kestrel · · Score: 1

      Unless of course, said malware is sniffing all your keyboard traffic, looking for that magic "su - " command.

    23. Re:Critical Bug? by ozmanjusri · · Score: 1

      And you know this because...?

      I'm dead and I'm not getting any.

      --
      "I've got more toys than Teruhisa Kitahara."
  4. Managed code by HeaththeGreat · · Score: 2, Funny

    This is why we need more managed code.

    1. Re:Managed code by Anonymous Coward · · Score: 0

      God, I hope you're joking.

    2. Re:Managed code by Johnno74 · · Score: 1

      No, he's dead right. Managed code is not vulnerable to buffer overflow/underflow attacks. If one occours, the runtime (java or .net) will detect it and raise an exception before any data is corrupted.

    3. Re:Managed code by frisket · · Score: 1
      Managing the code won't solve all the problem:

      It is not just images, but any type of complex file format.

      For 'complex', read 'proprietary'.

    4. Re:Managed code by plalonde2 · · Score: 2, Interesting

      But all the managed code's libraries weren't necessarily written in managed code. It's easy to see how "trusted" formats can have various pointer-arithmetic unchecked. Consider an image format that includes an offset to the start of some of its data: intercept the image, change the offset, and off you go at least feeding bad data to the application. Few loaders check that all these kinds of binary data are in range, programmers are lazy and just add the offset to their pointer :-( I guess more and more loaders will be checking more carefully now...

    5. Re:Managed code by Johnno74 · · Score: 2, Insightful

      I think the GP post's point is the loader should be written in a managed language... and I agree. Eventually I think we'll see unmanged code regarded in the same way as inline assembly is today - great for the places where you need absolue balls to the wall performance, but otherwise stay away from it.

      Lets face it, except for corner cases managed code is usually within a few % of the same speed as unmanaged code, and that few % isn't always on the slow side either.

      Of course its possible to write crap managed code, but its a hellava lot easier to write good managed code than good unmanaged code.

  5. woot by johann8384 · · Score: 0, Redundant

    again.....

  6. Practice safe image viewing folks! by nizo · · Score: 5, Funny

    Or your computer could get an STD (Screenally Transmitted Disease) from viewing pornographic images.

    1. Re:Practice safe image viewing folks! by Crimsane · · Score: 2, Funny

      Phew, i'm safe.

      My computer has already been crippled from a number of trojans...

    2. Re:Practice safe image viewing folks! by oberondarksoul · · Score: 4, Funny

      I get enough funny looks from my housemates already. I am not putting a condom over my monitor.

      --
      And tomorrow the stock exchange will be the human race
    3. Re:Practice safe image viewing folks! by Antique+Geekmeister · · Score: 1

      You've never used a keyboard condom? They're awfully handy for keeping contaminating fluids out of your keyaobrd.

    4. Re:Practice safe image viewing folks! by jrockway · · Score: 1

      > your keyaobrd

      Unfortunately they apparently make typing difficult.

      --
      My other car is first.
    5. Re:Practice safe image viewing folks! by Anonymous Coward · · Score: 0

      Placing a condom over your monitor won't solve the problem. It's like placing a condom over your head. Just make sure to surf safe and use a condom on your male network connector.

  7. Ack! by rubberbando · · Score: 5, Funny

    So now not only will looking at the goatse picture make you vommit, it will take over your Windoze PC!

    Will the horrors ever stop?!!

    --
    DEAD DEAD DEAD DELETE ME
    1. Re:Ack! by nizo · · Score: 1

      After seeing the goatse image the horror never ends, at least not without a carefully aimed icepick. Of course then the problem is you will forget you saw it before and go see it again later :-(

    2. Re:Ack! by Mistshadow2k4 · · Score: 1

      You obviously haven't seen Tubgirl yet. No, I'm not posting a link (Ick!!!!!)

      --
      I dream of a better world... one in which chickens can cross roads without their motives being questioned.
    3. Re:Ack! by Anonymous Coward · · Score: 0

      "at least not without a carefully aimed icepick..."

      Caution, do not look at goatse with remaining good eye...

    4. Re:Ack! by cbiltcliffe · · Score: 1
      So now not only will looking at the goatse picture make you vommit, it will take over your Windoze PC!
      But after seeing goatse, do you ever want to use your computer again, anyway?
      --
      "City hall" in German is "Rathaus" Kinda explains a few things......
    5. Re:Ack! by Anonymous Coward · · Score: 0

      What a security hole!

      Absolutely could not resist. My apologies.

    6. Re:Ack! by Doctor_Jest · · Score: 1

      At least don't look at goatse without your peril-sensitive sunglasses! .... oh man, I feel old now. :)

      --
      It's the Stay-Puft Marshmallow Man.
  8. So, Windoze merely has an image problem? by Anonymous Coward · · Score: 2, Funny

    It's not really a fundamental flaw?

    1. Re:So, Windoze merely has an image problem? by game+kid · · Score: 1

      I guess. In any case, I put their patch on my compy today. No side effects yet; let's <badImagePun>see what develops</badImagePun>.

      "It is not just images, but any type of complex file format. This is something that security researchers and hackers have realized to be a weak point in many applications."

      Hopefully they didn't just realize that.

      --
      You can hold down the "B" button for continuous firing.
    2. Re:So, Windoze merely has an image problem? by Anonymous Coward · · Score: 1, Interesting

      I just applied this patch to my Win XP x64 Edition box,
      and everything still functionally works ok, but there are
      tons of serious graphical glitches all over the OS now.
      I tried updating my video drivers (ATI x700, 5.9 to 5.10),
      that did nothing. Tried changing my color schemes, same thing.
      Finally tried removing the patch, and oh! things are back to normal
      now.

      Hooray for Microsoft! :-\

      D

  9. MSN Messenger felled by this months ago by saskboy · · Score: 5, Interesting

    Both jpg and png was flawed in Windows, MSN Messenger, and even other image apps by a buffer overflow exploit where a specially crafted jpeg file with a virus "attachment" would crash the program and execute virus code. I have to agree that if they are still finding flaws, we'll be stuck with them for a while. Just imagine, every Windows 98 computer out there probably has this problem too, and there's no way it's going to be really fixed. It will never be safe to run even "safe" things like jpg and mp3 on old computers now. It's very, very disapointing news.

    In a Messenger program that is always accepting new input in the form of pictures and messages, it's especially dangerous because anyone who's online will instantly become a zombie spewing out infection to their friends on their contact list. You really will get viruses through your personal contacts more than spamming-strangers in the future.

    --
    Saskboy's blog is good. 9 out of 10 dentists agree.
    1. Re:MSN Messenger felled by this months ago by webzone · · Score: 5, Informative

      the current flaw affects WMF (Windows Metafile) and EMF (Enhanced Metafile) file formats only. This is not the same thing as any jpeg or png-related vulnerability

    2. Re:MSN Messenger felled by this months ago by saskboy · · Score: 1

      The article, and I would disagree with you. "Microsoft in August warned of a similar flaw, which is related to an error in the way Internet Explorer handles JPEG images." It's similar because they are all image types, that can be "displayed" in a webpage automatically by default, and thus execution of the virus is not dependent on user intervention such as a double click.

      --
      Saskboy's blog is good. 9 out of 10 dentists agree.
    3. Re:MSN Messenger felled by this months ago by pogson · · Score: 1

      I am in the process of getting rid of the last Lose98 machine in my department. It's used as a print server and a GUI, unlocked, open to anyone who stumbles by.... shudder.... A Linux box is cued up and ready to go as print server with no mouse, keyboard or monitor. I just have to get the right memo out and dodge complaints that something on the network has changed. I do not think M$ is the problem. It's all the addicts who use the stuff. An OS that was obsolete the day it was installed and is still widely used 7 years later is an amazing artifact of a company that claims it is an innovator. It's more like a comic book super-villain who has frozen people in time...

      --
      A problem is an opportunity http://mrpogson.com
    4. Re:MSN Messenger felled by this months ago by Anonymous Coward · · Score: 0

      And that SAME bug was found in the Linux jpeg library as well!

    5. Re:MSN Messenger felled by this months ago by Anonymous Coward · · Score: 0

      Mod PaERNT teh FUnnay!!!!

      He said "Lose98"!!!!!111

    6. Re:MSN Messenger felled by this months ago by Anonymous Coward · · Score: 0

      > It will never be safe to run even "safe" things like jpg
      > and mp3 on old computers now.

      Translation: It will never be safe to play my mp3s that I downloaded off the net now.

      The only mp3s I have were ripped myself, from cds that I own. The only JPGs on my secondary machine are what came with the OS (98SE), my software and my digital camera. As long as an old Windows computer isn't connected to the internet it should be fine.

    7. Re:MSN Messenger felled by this months ago by saskboy · · Score: 1

      "
      Translation: It will never be safe to play my mp3s that I downloaded off the net now."

      Sort of. But think of a virus that infects your MP3 files you've made, so that now they aren't a "Safe" data type to save in the event of a suspected or known virus attack on your computer. There used to be files that could be considered "uninfected" when you backed them up, like .mp3, .jpg, .gif, .txt. How much longer until .txt is hosed too?

      --
      Saskboy's blog is good. 9 out of 10 dentists agree.
    8. Re:MSN Messenger felled by this months ago by Steeltoe · · Score: 1

      ust imagine, every Windows 98 computer out there probably has this problem too, and there's no way it's going to be really fixed. It will never be safe to run even "safe" things like jpg and mp3 on old computers now. It's very, very disapointing news.

      Why not install Linux or BSD on those boxes. It'll be more legal, and you get Free updates and security fixes. Windows 98 has always been disappointing, so why not do something about it?

    9. Re:MSN Messenger felled by this months ago by saskboy · · Score: 1

      What modern Linux distributions will work on a 486 and Pentium with only 16MB of RAM? Will it be updatable through a web apt-get type feature? The only one I know that in theory works is DSLinux, but it's a live CD not an install.
      What graphical system do I use?

      Windows is easy, and should work, it's a shame really that it has bugs like this that aren't fixed.

      --
      Saskboy's blog is good. 9 out of 10 dentists agree.
    10. Re:MSN Messenger felled by this months ago by wild_berry · · Score: 1

      Debian is at a comparable tech level with that hardware [/me ducks]. But seriously, Debian Etch/Sid on my P166 notebook runs Gnome 2.10 under an Xorg Xserver fine. But I did feed it lots of RAM. Before that it was running DamnSmallLinux installed to the HDD using the supplied scripts, taking up less than 300MB. It uses Xvesa and Xfb and a lightweight window manager; Dillo works great for a web browser, but Gecko-based browsers are a bit memory hungry.

  10. no no no... by soapdog · · Score: 1, Funny

    There's no such thing as vulnerabilities, all there's is Inteligent Bug. The exploits are there just to test your faith...

    --
    -- Por mais que eu ande no vale das trevas e da morte, meu PowerMac G4 Não Travará!!!
  11. Of Course by NanoGator · · Score: 2, Interesting

    Of course, I think the developers who left these vulnerabilities open should be financially responsible for the damage this may cause.

    --
    "Derp de derp."
    1. Re:Of Course by Anonymous Coward · · Score: 0

      Holy shit, you cant actually be serious. You must not be a software developer, or at least not a smart one to not worry about the burden of liability.

    2. Re:Of Course by Kelson · · Score: 1

      Would you expect the same to apply to the authors of, say, libpng? Or libungif?

    3. Re:Of Course by FLAGGR · · Score: 1

      They didn't leave them open, they didn't realize they existed. Either way, should makers of cars be held financially responsible for every bit of damage caused by missles hitting them, just because they didn't make the cars out of indestructable materials? This just in - cars vulnerable to anti-vehicular missle launchers. NanoGator thinks the car manufacturers should be held accountable. Abuhhhhh

      Anyways, unless you've done software development, your opinion doesn't matter.

    4. Re:Of Course by Anonymous Coward · · Score: 1, Interesting

      Actually, I posed this in both this thread and in the Lupper thread. Just curious if there's a different opinion depending on whether the victim of maliciuos code was Microsoft or Linux. Unfortunately, I picked a bad specimen here since MS didn't write that lib and the other thread was looded with comments by the time I got it. Oh well.

      So, no, I wasn't serious.

    5. Re:Of Course by Scarletdown · · Score: 1
      should makers of cars be held financially responsible for every bit of damage caused by missles hitting them, just because they didn't make the cars out of indestructable materials?
      I truly hope they don't start making cars out of indestructible materials, because after having to deal with so many idiot drivers out there over the years, I'm actively lobbying for a law to make Sidewinder missiles legal for personal use... At least, for my personal use. :D
      --
      This space unintentionally left blank.
    6. Re:Of Course by Dragoonmac · · Score: 1

      I agree completely, they should buy everyone who's computer was infected a brand new, secure copy of linux.

      --
      Shots: A Populist Parable
    7. Re:Of Course by Anonymous Coward · · Score: 0

      > I agree completely, they should buy everyone who's computer was infected a brand new, secure copy of linux.

      Oh yeah, they'll surely escape negligent exploits that way. And think of the productivity gains those users will recieve when all their games stop working!

    8. Re:Of Course by SilverspurG · · Score: 1

      If they follow the strict spec for the codec, there wouldn't be any problem.

      I half expect that codecs with exploits are products of IP battles. "We can't do it the right way, but if we do it this way we can still achieve the same compression/decompression algorithm--albeit with a potential code fault."

      Long live IP for MS. The Open Source King kives.

      --
      fast as fast can be. you'll never catch me.
    9. Re:Of Course by Mistshadow2k4 · · Score: 2, Interesting

      Here's why these things happen so much with Windows: no developer ever sees all of the code, only their own portion. They don't work together. One developer has few, if any, clues what the other developers are doing. This is Microsoft's idea of securing the code (Didn't work, did it?)

      Traditionally, Microsoft Windows is built by thousands of software engineers, each producing their own segments of code that are stitched together into one program. From Microsoft Admits Trouble with Windows

      Imagine it this way. Joe, Bob, Dave and Greg are coding a program. Each of them is assigned different parts of the same program. Bob's code conflicts with Greg's. Dave's code covers part of what Joe wrote, but accomplishes the same thing in a different fashion. Nobody writes a bit of code that would protect the program from a vulnerability to a certain file type.

      Now multiply that by a few hundred, like a freakin' huge patchwork quilt added onto and re-sewn by generations of half-blind seamstresses. That's how Windows has been written, from 95 and on. So are the indivdual developers to blame? Some certainly could have been lazy or just mistaken (and probably have been). But since Microsft has deliberately made the code for their OS into such a total mess, how could you find out which developers to hold responsible? So you see, the problem isn't really Micorosoft's developers, it's Microsoft the company.

      Now, normally, I'd agree with you. If you've got, say, 20 developers on a project working together and a vulnerability like this crops up, they are directly resposible. But in a case when they are effectively working blind at the company's behest, they don't know what their co-workers are doing or have done, so they can truthfully say they only did the part they were supposed to and wasn't that supposed to be taken care of by Department Z and not even be passing the buck, just confused.

      --
      I dream of a better world... one in which chickens can cross roads without their motives being questioned.
    10. Re:Of Course by Teckla · · Score: 1

      Of course, I think the developers who left these vulnerabilities open should be financially responsible for the damage this may cause.

      I'm amused your comment has been rated interesting, when you're clearly joking. (You are joking, aren't you?)

      For those that don't get it: If software developers and software companies were responsible for every little bug, (1) Programs like Notepad would cost tens of thousands of dollars, and (2) Free software wouldn't exist.

      Nobody would be able to afford the legal risk of being a software developer.

  12. When writing a parser, length checking is a must by Harry+Balls · · Score: 5, Interesting

    When writing a parser (for a graphical or non-graphical data file) it is advisable to sanity check the input data at every step.

    Consider ASN.1 data (used, for instance, for digital certificates, certificate revocation lists, certificate requests and so on).
    Each and every ASN.1 data element and each and every sub-element contains a length field. The ASN.1 parser should check whether the length field of a sub-element goes beyond the length of the enclosing data element, and so on ad infinitum.
    If the parser detects a violation, parsing stops.

  13. Hah! by Anonymous Coward · · Score: 0

    And I was that dude who told them (in an eMail) that their IExplorer should get the transparency in png's right! ...OR ELSE!

  14. To Finish Microsoft's Quote..... by Khyber · · Score: 1, Funny

    I love how Microsoft puts this... "We will continue to see this type of vulnerabilities in every major application for the foreseeable future..."

    Lemme finish off that ... for them. "... until we learn that integrating IE directly into the OS was the biggest fuckup we ever made."

    Seriously, why integrate something so seriously flawed into the OS? The only thing it'll do is make the system less stable and less secure.

    --
    Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
    1. Re:To Finish Microsoft's Quote..... by drsmithy · · Score: 2, Interesting
      Lemme finish off that ... for them. "... until we learn that integrating IE directly into the OS was the biggest fuckup we ever made."

      Let me guess, you're one of these dimwits who think "integrating IE directly into the OS" means it's part of the kernel ?

    2. Re:To Finish Microsoft's Quote..... by Khyber · · Score: 1

      No, I'm one of those dimwits that KNEW integrating the application into the OS itself, would create more problems. Did I mention KERNEL anywhere in that post? No. Modular OSes tend to be a bit more secure than something that has everything built-in. It's harder to exploit holes when crap isn't directly tied to and dependent upon everything else.

      --
      Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
    3. Re:To Finish Microsoft's Quote..... by drsmithy · · Score: 1
      No, I'm one of those dimwits that KNEW integrating the application into the OS itself, would create more problems. Did I mention KERNEL anywhere in that post? No. Modular OSes tend to be a bit more secure than something that has everything built-in. It's harder to exploit holes when crap isn't directly tied to and dependent upon everything else.

      So what makes you think IE is any different to khtml in KDE and WebCore in OS X ?

    4. Re:To Finish Microsoft's Quote..... by Khyber · · Score: 1

      KDE doesn't need patches nor leaves massive vulnerabilities for others to exploit, for one. Of course, that's mainly on the OS itself. Making IEtie in with outlook/messenger and other things was just ignorant. several programs linked together, all with massive vulnerabilities, and wham, Microsoft gets slammed with everything while most other OSes stay secure because everything is separate for the most part from everythign else. On this note would you happen to be an OS designer? If so, you could've simply explained things to me, instead of being a dickhead off the bat like some typical 14 year old from WoW

      --
      Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
    5. Re:To Finish Microsoft's Quote..... by drsmithy · · Score: 1
      KDE doesn't need patches nor leaves massive vulnerabilities for others to exploit, for one.

      KDE doesn't get patched ? Bullshit.

      Making IEtie in with outlook/messenger and other things was just ignorant.

      Just like the khtml or WebCore modules can be reused in other KDE or OS X apps, you mean ?

      IE is the equivalent of a shared library. Of *course* other applications are going to use its functionality - that's the whole reason it was designed the way it is. Do you similarly blame "the OS" when a glibc vulnerability affects a wide range of Linux software ?

      If so, you could've simply explained things to me, instead of being a dickhead off the bat like some typical 14 year old from WoW

      You're the one who started criticising from a position of ignorance. It's pretty clear you don't understand that IE's architecture is just like khtml, WebCore, or dozens of other reusable components.

      Or, to put it another way, you're saying something sucks, when you don't actually know anything about it and it has since been emulated by both the two major Linux GUIs and OS X.

      Now, if this was a recent development in IE's history, I'd be inclined to consider your ignorance to be an innocent mistake. However, since IE has been designed like this for *nearly 10 fucking years*, and that design has since be imitated by KDE, GNOME and OS X, it's pretty obvious you're just mindlessly regurgitating typical Slashbot anti-Microsoft FUD of "Windows sucks because IE is 'part of the OS'". That is why I responded as I did.

      There is nothing special about IE. It's just a bunch of shared COM components. It runs in user space. It runs with the privileges of the user. It doesn't hook into the kernel. It doesn't have any special abilities. "Part of the OS" just means it comes by default and other applications can depend on it being there, like the widget set. It's simply implementing one of the basic tenets of good software design - reusable code.

      If you really feel the need to criticise IE, at least learn enough about it to criticise it from a position of non-ignorance, and pick some of the things that need to be fixed, like ActiveX or coding bugs.

    6. Re:To Finish Microsoft's Quote..... by Khyber · · Score: 1

      Do you similarly blame "the OS" when a glibc vulnerability affects a wide range of Linux software? Seeing as none of my Linux boxes have had any problems, EVER, I'll just claim ignorance of glibc vulnerabilities. Only Linux problem I've ever had was installing OpenGL for my nVidia card.

      It doesn't hook into the kernel If that's the case, how does it run, native communication on the binary level with the CPU itself? I didn't think so. Something that controls it HAS to communicate with the Kernel, elsewise, it ain't running. I seriously doubt IE could be programmed to use the bare Command.com and function properly.

      AS for me picking on IE, I've got hundreds of good reasons why, and the best one being it cost me over $50,000 worth of information and my personal business records and tax files. Thank you ActiveX - WHICH I REGULARLY CRITICIZE. Half of what ActiveX does could be done almost as easily (with more time involved due to typing out extended code) in regular CGI-script on a basic HTML webpage, minus USELESS crap like Sony's current need of ActiveX to be able to uninstall DRM. BTW, from my "position of ignorance" I've been running computers and programming since I was 4, using a TI 99/4A and the BASIC programming language. I've got a good grasp of what goes on in any Windows installation, because my first instinct is TAKE THE DAMNED THING APART AND SEE HOW IT WORKS. I can have Windows 98 down to using 12 megs and being fully functional. And that's by forcing IE completely out of the equation and re-hooking other calls to the kernel to interpreters, as the first step. Re-code some stuff in delphi, compile, test. Took four years but it's done, now. My next step is total removal of Explorer from XP and using mIRC as the GUI/Shell/Manager. Here's a snapshot of the current progress.

      --
      Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
  15. Another brownie point for the cause of DRM? by xclay · · Score: 2, Interesting

    It's a tangental thought, but the debate around online security, including this one, seems to be paving a wide path for DRM, or more centrally-managed content distribution methods in commercial applications.

    1. Re:Another brownie point for the cause of DRM? by plover · · Score: 4, Insightful
      I'm not sure how you extrapolated that. What makes you think the DRM code is going to be somehow "more resistant" to buffer exploits? It just shifts the focus from the "media viewer" portion to the "DRM decoder" portion of the software. But there are still buffers involved.

      Besides, if you're passing "unprotected" content around you'll still have these issues. Not every JPG is going to suddenly be digitally signed and encrypted. Assuming the same "media viewer" application, you'll have the same bugs.

      If anything, the DRM code just adds another layer of interpretation that's open to attack, making your system "less safe" rather than "more safe." More code == more potential for bugs.

      --
      John
    2. Re:Another brownie point for the cause of DRM? by xclay · · Score: 1

      I'm not sure how you extrapolated that. What makes you think the DRM code is going to be somehow "more resistant" to buffer exploits? It just shifts the focus from the "media viewer" portion to the "DRM decoder" portion of the software. But there are still buffers involved. Well, in an ideal world, the access to buffer itself would have to be managed through rights for security. As someone already mentioned, every single piece of data would have to be authenticated for the parser to give an okay. Besides, if you're passing "unprotected" content around you'll still have these issues. Not every JPG is going to suddenly be digitally signed and encrypted. Assuming the same "media viewer" application, you'll have the same bugs. If anything, the DRM code just adds another layer of interpretation that's open to attack, making your system "less safe" rather than "more safe." More code == more potential for bugs. Of course, I agree, I just think that we have to rethink the whole software development concept from a security-centric point of view. It seems that we're reaching some kind of threshold using the old model. Please excuse the generality, but many companies have been trying too hard with a minimal result. I think the answer may lie with some hardware-based solution disguised as a convenient periphery, and we're starting to see some of those already in financial sectors.

    3. Re:Another brownie point for the cause of DRM? by Clod9 · · Score: 1
      > What makes you think the DRM code is going to be somehow "more resistant" to buffer exploits?
      When I read the GP, I thought he meant DRM content, not code. If you can't trust your system to safely deal with whatever it encounters, then many consumers will be easily convinced that the solution is to guarantee that it only encounters trusted data.

      For instance, you don't just stick any old CD from a mass mailing into your drive and install software to see what it does, do you? Most people understand now that this is dangerous, and they only install programs from CD's they've bought or received from people they trust in some way. Now, if just looking at an image online can cause harm, then people will do the same thing with their browsers -- they will only surf sites they trust. To prevent the loss of ad dollars, the big site owners will work with the DRM suppliers to promulgate a model where the browser checks every piece of content to verify who made it, before attempting to deal with it. This will be a large hurdle in the path of independent content providers who aren't in on the scheme.

      In reality, we don't need all this. It is possible, and not really all that hard, to write a bulletproof algorithm to verify an image file format as it is being read, and it doesn't cost a lot of performance. The question is, will people demand this, or will they be lulled into accepting a continuous train of little "fixes" from their software supplier?

      (Or will people perhaps demand a virtual OS instance that will allow them to surf even the most evil sites in a pure read-only mode?)

    4. Re:Another brownie point for the cause of DRM? by cbiltcliffe · · Score: 1
      What makes you think the DRM code is going to be somehow "more resistant" to buffer exploits? It just shifts the focus from the "media viewer" portion to the "DRM decoder" portion of the software. But there are still buffers involved.
      Whether this is true or not doesn't matter in the slightest. If they set their mind to it, the corporations will pitch DRM as a solution to this type of problem, and the great unwashed masses will go "Ooooh. Look! They've solved the virus problem!!" and it won't even enter their heads that it's not the best way, or even an appropriate way to solve this particular problem. And somehow, when they still keep getting viruses, they won't make the connection that they were lied to.

      DRM could be marketed as the solution for everything from computer viruses to world poverty, and everybody but us geeks wouldn't even know enough to question it. Marketing is 3% reality, 97% perception, and most people don't have any frame of reference to base it in, so the perception wins out every time.

      Notice I didn't give any reference for my percentage figures, but it sounded good, so you didn't question it, right? That's marketing. Make something sound good to 98% of the population, and who cares whether it works or not. People will buy it.
      --
      "City hall" in German is "Rathaus" Kinda explains a few things......
  16. phishy... phishy... by lcde · · Score: 2, Insightful

    'We will continue to see this type of vulnerabilities in every major application for the foreseeable future ... It is not just images, but any type of complex file format. This is something that security researchers and hackers have realized to be a weak point in many applications.'

    In a later interview:"Only one known product suite on the market can protect you from these ongoing threats. MS-AntiVirus and MS-AntiSpyware. Only these two programs are equipt with the proper image handling algorithims to detect these known flaws inherent in all programs."

    This seems like a big scheme to get people on their proprietary AV and AntiSpyware programs. Lets see... Find hole, fix hole, release press release about hole, plug product, patch hole for product users.

    eesh.we will see.

    --
    :%s/teh/the/g
    1. Re:phishy... phishy... by Senzei · · Score: 2, Insightful

      So current vulnerabilities in microsoft image processing libraries are going to be used to promote a currently nonexistant (and possibly never-existant) commercial antivirus/antispyware system? What I want to know is where the tin-foil-hat code let you give someone your address so they could deliver all the crack.

      --
      Slashdot: Where anecdotes and generalizations can be freely substituted for facts, logic, or intelligence
    2. Re:phishy... phishy... by GrassyNoel · · Score: 0

      How about the first step: Create Hole.

      --
      Plus ça change, plus c'est la même chose.
    3. Re:phishy... phishy... by jrockway · · Score: 1
      --
      My other car is first.
  17. An interesting question by ThePyro · · Score: 5, Insightful

    Microsoft's .NET platform, which is supposed to be managed code, has built-in support for rendering WMF and EMF images (the image formats that are affected by this security vulnerability). So are applications written in .NET still vulnerable to the buffer overflow exploit, or was the underlying rendering code rewritten for the managed environment?

    Writing managed applications won't protect you (completely) if the underlying framework isn't also managed.

    1. Re:An interesting question by petermgreen · · Score: 1

      which it usually isn't for reasons of performance,compatibility with existing systems in the os and the desire not to rewrite code unnessacerally.

      i'd be very surprised if the .net calls for wmf and emf didn't call directly into the winapi functions for rendering wmf and emf.

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
    2. Re:An interesting question by zootm · · Score: 1

      His point — "This is why we need more managed code." — is still valid, though.

    3. Re:An interesting question by Anonymous Coward · · Score: 0

      I don't know about this particular vulnerability, but MS's .Net is largely com-interop wrappers around existing Windows services. Mono is a little more pure but even so it has wrappers around GTK.

      I don't see this as a bad thing when because it's the opposite to a Big Bang approach to software development. This way people can migrate to the managed platform over time, and people don't miss out of their favourite bit of software in the meantime. It's evolution, not revolution.

      Search Google for the MSDN article "The Myth of .Net Purity" for more.

    4. Re:An interesting question by dgatwood · · Score: 2, Interesting

      No, it isn't. There are plenty of ways to fix programming languages so that they don't have a risk of buffer overflow exploits without the performance hit of some bloated vitual machine. All that is really required is for there to be a lot stricter checking when doing operations involving pointers.

      Change the following:

      1. No static buffers. All buffers declared in a static fashion should be replaced by run-time dynamic buffers of the same size. This way all data objects are managed by malloc. This creates a slight performance hit, but not much. This alone nearly eliminates the possibility of buffer overflows resulting in execution because arrays are never on the stack.
      2. Make each malloc store the size of the region right before the pointer. Then, when the compiler generates an array dereference (the first time it does so for a given index), it should do something like "cmp index,0; bl ERROR; cmp index, @(baseptr-4); bge ERROR;" where ERROR triggers a segfault programmatically.
      3. Pointer arithmetic: the in-memory storage for a pointer should be increased to twice the actual architectural size of a pointer. When arithmetic occurs, the pointer should be stored as a base followed by an offset. This way, the original base address is always available, and thus, the original size is always available.

      It's easy to very nearly eliminate these problems without every memory access being managed through a virtual machine. It's easy to fix this without a heavyweight runtime environment. It's easy to fix this without any changes to the C language at all beyond the compiler level. So why don't we? If the choice is between a relatively small performance hit doing array bounds checking and a huge performance hit from everybody doing this managed code crap, the decision should be a no-brainer....

      --

      Check out my sci-fi/humor trilogy at PatriotsBooks.

    5. Re:An interesting question by owlstead · · Score: 1

      My GUESS is that they are being rewritten in Vista/Longhorn. On Windows 2k and XP .NET uses a lot of wrappers. And since you cannot guess how big an image is supposed to be, you will still suffer buffer overruns. Java has a very small interface to native libraries, and with good reason (also for portability of course).

    6. Re:An interesting question by SilverspurG · · Score: 4, Insightful

      How about we just raise the bar on coding practices and actually secure programming? Maybe we could teach strict logic flow structures.

      The biggest excuse I hear from programmers for why they've violated strict logic flow is always,"Well, I was coding for speed and efficiency". With 3.0+GHz machines, what does it matter anymore? It's all a lot of hooey, too. The person learned that excuse from someone in 8th grade and they've latched onto it. When pressed they rarely even know what logical structure they've violated. They only know the excuse.

      I think the biggest problem facing us is the inundation of object oriented programming languages. There's very little need to learn the strict mathematics of programming anymore. It is this laziness, and not any particular language, which is the root cause of the problem. Programming environments with sandboxes (ie. Java) are band-aids to a bigger problem.

      The problem is with lazy programmers.

      --
      fast as fast can be. you'll never catch me.
    7. Re:An interesting question by KarmaMB84 · · Score: 1

      It's called checking buffer lengths rather than trusting the file itself... it's something we didn't used to think about ;)

    8. Re:An interesting question by zootm · · Score: 1

      One could enforce using a system in object space, rather than memory space, too, and compile this to native code with little or no peformance loss — this is what the Microsoft's research project Singularity, mentioned on here not long ago, is suggesting.

      Back to the topic, though, in practice, the performance hit of managed code is negligable in most cases, and the extra safety it provides is far more valuable. Nobody can write bug-free code. Making entire classes of serious bugs impossible to implement is a very good thing.

      There's a few more problems, unfortunately, to C than you allude to, but there is work in creating a C-like language which is more safe — Cyclone comes to mind if you're interested. :)

    9. Re:An interesting question by UncleFluffy · · Score: 2, Interesting

      The problem is with lazy programmers.

      I've posted this before on Slashdot, so apologies for the dupe, but...

      My first technical question in an interview is "what is wrong with this C code?"

      void echo(void) { char *s; gets(s); puts(s); }

      Over 50% of the "experienced C coders" I interview fail to get the answer right, and this has been a constant for about the last five years. Scary, isn't it? What's even scarier is when an employer hires them after I've flagged this in the post-interview chat.

      --

      What would Lemmy do?

    10. Re:An interesting question by TummyX · · Score: 1


      I don't know about this particular vulnerability, but MS's .Net is largely com-interop wrappers around existing Windows services


      Actually, it's mostly interop over existing windows apis (not com). System.Drawing is based on GDI+ which is a C library.

    11. Re:An interesting question by rblum · · Score: 2, Insightful

      Oh, great. Another person testing for memorization of language details. The correct answer is, of course: "It will not compile, since you forgot to provide headers". (Yes, I know the problem with gets - but smart-ass questions get smart-ass answers. And it actually does matter - who am I to say if you don't have your own version of gets?)

    12. Re:An interesting question by TClevenger · · Score: 1

      I'm not a programmer, but I'm interested in the answer. Can you elaborate?

    13. Re:An interesting question by SilverspurG · · Score: 1

      I must admit that I'm only just now entering Chapter 2 of "The C Programming Language" by Kernighan and Ritchie. My education with logic flow and structured programming came at a time when QuickBASIC was the focus language. Still, though, the same sqaures/tetrehedrons/circles still apply.

      Provided that the programmer is adhering to all of the standards and protocols of gets() and puts(), there's nothing wrong with what you've written. I suspect that the bug is somewhere in a difference of semantics between gets() and puts(). Obviously, if the programmer were worth their degree, any sanitization would be properly coded between gets and puts.

      As another poster said: you're probably pointing out semantics.

      --
      fast as fast can be. you'll never catch me.
    14. Re:An interesting question by sam0737 · · Score: 1

      Then you can offically blame Microsoft for your bug. =P

    15. Re:An interesting question by UncleFluffy · · Score: 1

      Another person testing for memorization of language details.

      Well, I did say that these people claimed to be "experienced". If someone needs to look up something that trivial then I wouldn't count them as experienced.

      The correct answer is, of course: "It will not compile, since you forgot to provide headers".

      Fair enough, and I'd give a small amount of bonus points to someone who said that before writing in the #include directives and asking the question again.

      (Yes, I know the problem with gets - but smart-ass questions get smart-ass answers. And it actually does matter - who am I to say if you don't have your own version of gets?)

      Actually, they don't need to know anything about gets() or puts() to answer the question correctly. If it was C++, then they would. All they need to know is how pointers are passed to functions, which is very very basic knowledge.

      --

      What would Lemmy do?

    16. Re:An interesting question by cbiltcliffe · · Score: 5, Funny

      I was going to point out that "unnessacerally" was spelled incorrectly. I was then going to suggest that you could use Google as a spell checker, by typing your spelling into it, and seeing what it suggested with its "Do you mean...." thing.

      Then I went and typed that spelling into Google, and found out that enough people have spelled it incorrectly on the web that Google doesn't know how to correct it, and suggests another incorrect spelling.

      Correct spelling is "unnecessary".

      Now, mod me down as a pedantic twit.

      --
      "City hall" in German is "Rathaus" Kinda explains a few things......
    17. Re:An interesting question by UncleFluffy · · Score: 1

      I must admit that I'm only just now entering Chapter 2 of "The C Programming Language" by Kernighan and Ritchie.

      I can't remember the order of chapters in K+R, but skip ahead to the chapter on pointers and see if you still think that the code is OK.

      --

      What would Lemmy do?

    18. Re:An interesting question by cbiltcliffe · · Score: 1

      Actually, correct spelling would be "unnecessarily", to match your use of the word.

      Duuh. Eye shud akchoowally prufe-reed, shudnt eye?

      --
      "City hall" in German is "Rathaus" Kinda explains a few things......
    19. Re:An interesting question by UncleFluffy · · Score: 1

      I'm not a programmer, but I'm interested in the answer. Can you elaborate?

      Well, the technical details should come out in the replies, Slashdot being the abode of geniuses that it is, but basically it's a flaw that (a) shows lack of understanding of some of the basic concepts of programming in C, (b) opens up the code to all sorts of attacks, and (c) makes the behaviour of the code completely unpredictable.

      There's a second flaw related to using an unsafe library function that gets them bonus points if they spot it, but that's not the key point.

      I expect "experienced" people I interview to spot the flaw by reflex - if they have to think about it, then I will dig further. If they don't get it, then they shouldn't be programming C for a living, and I wouldn't hire them for anything other than a trainee position.

      --

      What would Lemmy do?

    20. Re:An interesting question by Mike+A. · · Score: 1
      Do I only get to pick one thing? Because there are two really serious errors with that code:
      • You aren't allocating a buffer for the string pointer you're passing to gets().
      • You're using gets().
      --

      --
      Do I look like I speak for my employer?
    21. Re:An interesting question by UncleFluffy · · Score: 1

      The dangling pointer is the key issue, spotting that gets() is unsafe gets bonus points.

      --

      What would Lemmy do?

    22. Re:An interesting question by Mortlath · · Score: 1
      it's something we didn't used to think about

      Too true. In defense of the original programmers, who would have thought that someone would purposely write bad image files in order to run arbitrary code?

      On the other hand, I suppose that they could have considered the possibility of corrupted files.

      Computer security methods have changed over the years. The code base just needs to catch up.

    23. Re:An interesting question by SilverspurG · · Score: 1

      Ch. 5 is Pointers and Arrays. Ch. 6 is Structures.

      You don't mind if it takes 3 mos. for a reply, do you? :)

      --
      fast as fast can be. you'll never catch me.
    24. Re:An interesting question by Antique+Geekmeister · · Score: 1

      No, it's not. I've actually resigned from a job rather than engage in ludicrously unsafe practices, told by my boss to neglect security for a client that was in the contract in order to spend my time on software issues that were supposed to make the client forgive us for the deadlines we'd already missed. That didn't fix the practices, but it did get my name off them and let the client know I was unhappy about it.

      Sometimes stupid or unsafe security practices are engaged in to save time or make a deadline, and especially to permit demoware to make a big sale. Demoware is death to secure computing, because what is a one-off is so often becomes a permanent feature.

    25. Re:An interesting question by Anonymous Coward · · Score: 0

      The correct answer is, of course: "It will not compile, since you forgot to provide headers".

      If it's old enough C, you don't need headers. The compiler will assume those functions take whatever parameters you give them and return int. (I don't remember whether the latest standard still allows that, but I'm assuming it doesn't.)

      Anyway, it's clearly just a piece of a program and probably not intended to even be an entire compilation unit. There's no main function, so it won't link either.

      Yes, I know the problem with gets - but smart-ass questions get smart-ass answers.

      There's a more fundamental problem than gets here.

      This is a prime example of why you don't want to be a smart ass to these sorts of questions; if you're wrong, you end up looking like a dumb ass instead.

    26. Re:An interesting question by sahirh · · Score: 1
      No static buffers. All buffers declared in a static fashion should be replaced by run-time dynamic buffers of the same size. This way all data objects are managed by malloc. This creates a slight performance hit, but not much. This alone nearly eliminates the possibility of buffer overflows resulting in execution because arrays are never on the stack.
      This will only stop you from executing code on the stack (the typical 'stack smashing' attacks), your problem now become heap overflows, vulnerabilities where one malloc'd buffer overruns into the next chunk, overwriting management information. When free() is called, the pointers in the management header of the block can be made to do interesting things. In the classic buffer overflow, the 'buffer' is merely used as a storage space for the arbitrary code -- this is not a requirement, the attacker can store his code in an environment variable, or perhaps even just overwrite important data that is used elsewhere in the programs logic (pointers, function pointers, authentication flags etc etc, use your imagination). Bounds checking can be difficult, imagine a seemingly safe routine where the coder uses strncat in a loop to add to the end of a buffer, at first glance, the code seems safe since it uses a 'safe' function, however what if the coder neglects to recalculate the last parameter to strncat in each loop iteration (it should reflect the amount of space REMAINING in the buffer, not the actual size of the buffer), you straight away have a buffer overflow here. The only way to solve this problem is to *teach* coders how to write proper code. Any code branch where user supplied input is processed should be subjected to extremely rigorous sanity checking, preferably through a white list of 'allowed input' rather than a blacklist of 'disallowed input' Think of this as analogous to firewall rule writing 'that which is not expressly allowed is disallowed' is much safer than 'that which is not expressly disallowed is allowed'.

      --Sahir

      --
      :wq
    27. Re:An interesting question by qazsedcft · · Score: 1

      But the devil is in the details. Most bugs are like that. If someone can't spot a bug in a one line program how are they supposed to spot the real bugs in larger programs?

    28. Re:An interesting question by fishbot · · Score: 1

      Of course you know the problem with gets(). That's why you'd use fgets(), like this:

      fgets(s, ?, stdin);

      where ? is replaced with the size of the buffer. Oh wait ... how much memory did we allocate to the buffer?

      Smart-ass answers to apparently smart-ass questions just make you look silly. It wasn't a smart-ass question about gets(), you just assumed it was. That's as telling about your attitude as it is about your ability to detect bugs in code.

    29. Re:An interesting question by UncleFluffy · · Score: 1

      Thanks. I didn't want to say it quite as bluntly as that, but I appreciate it very much that someone did.

      --

      What would Lemmy do?

    30. Re:An interesting question by Alioth · · Score: 1

      Gah. If you think this is 'testing for memorization of language details', you cannot ever claim to be an experienced C programmer (i.e. the people the original poster is interviewing). The answer is blindingly and instantly obvious to any (genuinely) experienced C programmer who should be able to point out two fatal flaws with that code snippet without even having to think about it, and what's more, explain cogently why those flaws are indeed fatal.

      I wouldn't hire a C programmer who passed themselves off as 'experienced' if they couldn't instantly spot what was wrong with that code.

    31. Re:An interesting question by Aceticon · · Score: 1

      I would say it's a mix of:
      - Too many way off project plans & impossible deadlines, leading to programmers doing rush jobs of implementations & bug filled late-night coding sessions. This is a management problem.
      - Inexperienced programmers.
      - Prima Donna programmers that do things "their way" which "requires no documentation" because it's so "obvious", without even considering that other programmers that will have to create extensions to their code or have to produce applications interacting with that code are not omniscient or mind-readers and cannot guess out of thin air "the right way to use/extend it".

      Proper error handling, proper design and proper documentation (especially on software that's supposed to be used by other software) are the sort of practices that should be followed to minimize this kind of things.

      In my experience, following or not this kind of good practices is quite independent of the programming language used.

    32. Re:An interesting question by igb · · Score: 1

      I've been writing C on and off for twenty years, and I'm worried by the phrase ``the answer''. It'll crash and burn because the uninitialised pointed s is going to point into unallocated memory. But no-one should be using gets in the first place, even if they have initalised the space, because it doesn't make any checks on the memory it has available to it.

      But if the point is to show how exploits are written, it's not a terribly good example. My understanding is that the menance for stack smashing is not this mistake:

              char *s = malloc (100);
              gets (s);

      but this

            char s[100];
              gets (s);

      The critical difference is that in the latter case, the buffer exists on the stack, so a later user of it can overrun it and mangle the frame pointer. I'm not an elite hacker dude, so I may be wrong here.

      ian

    33. Re:An interesting question by maxwell+demon · · Score: 1

      You missed another problem: The pointer s is not initialized.

      --
      The Tao of math: The numbers you can count are not the real numbers.
    34. Re:An interesting question by igb · · Score: 1
      The dangling pointer is the key issue, spotting that gets() is unsafe gets bonus points.
      So why not frame your question in terms which only admit the answer you're looking for? The same question but using fgets highlights the dangling pointer issue. I spotted both, obviously, but I'd regard the dangling pointer as a bug that would get caught in development while I'd regard the use of gets as far more insidious. After all, with the dangling pointer, the code simply won't work on most architectures. gets `works', and the reasons why it's crap won't be shown by anything this side of very agressive testing.

      ian

    35. Re:An interesting question by lifespan · · Score: 0

      This is a prime example of why you don't want to be a smart ass to these sorts of questions; if you're wrong, you end up looking like a dumb ass instead...

      It seems all who posted to this thread were some variety of ass. Dumb ass, crawling up the potential boss' ass, elitist jackass etc etc

      --
      -- Howto: Get +5 (1) Whine about M$ (2) Namedrop Gentoo (3) Casually Abuse Mods (4) Namedrop Early Computer Model
    36. Re:An interesting question by maxwell+demon · · Score: 1

      The function is badly named, because as everyone should know, echo prints its arguments, not standard input. :-)

      --
      The Tao of math: The numbers you can count are not the real numbers.
    37. Re:An interesting question by UncleFluffy · · Score: 1

      So why not frame your question in terms which only admit the answer you're looking for?

      Because it's in the context of an interview. Open-ended questions are far more revealing about someone's thought processes. I don't just want a single Boolean result - I want a window into someone's head.

      --

      What would Lemmy do?

    38. Re:An interesting question by dgatwood · · Score: 1
      Not only is it uninitialized, it is a potentially arbitrary value coming from the stack. This could open up security exploits in subtle ways. For example... assume that for some reason, it isn't possible to create a buffer overflow with a single variable that results in execution of code. For example, assume that you have only one funciton with a large enough buffer to be usable, but it is followed by a pointer that gets dereferenced after the buffer is filled (and would thus segfault if you overwrote it with arbitrary data).

      The variable can never be realized to a known value except through a security hole. Dereferencing this pointer would normally cause a segfault. However, if there were a pointer at that spot in the stack in the previous function, the code might actually inadvertently depend on the previous function leaving some value there and might behave correctly.

      In such a situation, you should be able to see all sorts of possibilities for new exploits.... Overwrite the pointer to point to some other, larger buffer (like the one that existed in the earlier function that couldn't be safely overflowed). Now, you can potentially cause a two-tier buffer overflow using a VERY small buffer in this second function, which probably wasn't vulnerable before because of prior bounds checking on the original pointer.... Of course, exploiting this requires two things: the stack must start at a constant address (common) and the function must always be called at the same stack depth (also fairly common). This is a fairly narrow exploit window, but by no means narrower than security holes that have been exploited in the past.

      Security is a tricky thing, and it is easy for a seemingly harmless error to turn into a nightmarish security hole. You shouldn't hire somebody for a QA position who couldn't catch such a glaringly obvious bug; forget a programming position. The GP's (or was it GGP, I lose track) management should be ashamed for letting such "programmers" through.

      --

      Check out my sci-fi/humor trilogy at PatriotsBooks.

    39. Re:An interesting question by rblum · · Score: 1

      Actually, they don't need to know anything about gets() or puts() to answer the question correctly. If it was C++, then they would. All they need to know is how pointers are passed to functions, which is very very basic knowledge.

      Apologies for the assumption that it was C++, not C. Rare are the places that can or do differentiate between the two. And yes, in that case it is indeed basic knowledge. Maybe I've just seen a couple too many really bad C++ interviews, so I'm overly sensitive.

    40. Re:An interesting question by rblum · · Score: 1

      Guess I deserved that smackdown. As I said above, I assumed C++. (And was in a bad mood...)

      I'm still maintaining you can only judge a person by having them *write* code, though. Throwing a made-up problem at them will lead to different assumptions, based on their backgrounds. Having them write code will force them to operate at least on a consistent set of assumptions - their own.

    41. Re:An interesting question by dgatwood · · Score: 1
      Actually, my proposed change takes care of all of those things. The compiled copy of strncat would be passed a pointer to a buffer, which as mentioned, would contain a base and an offset. Below the base is the size of the block. The compiled code for strncat would be compiled with the same compiler as your function, and thus, would contain the same bounds checking as your code.

      Thus, in strncat, prior to the first read or write access after the index value is changed (by a pointer increment) and prior to the first read or write access upon entering the function, the pointer position would be sanity checked against the size of the buffer. Thus, it would not be possible for this to overflow the buffer. Similarly, it would not be possible to overflow the buffer and overwrite any of the malloc/free management data. All for 2-5 extra CPU instructions.

      Also, if there are no buffers of any significant size at a location that can be determined without having read access to arbitrary bits of the memory space of the running executable, it becomes nearly impossible to write a viable exploit beyond jumps into existing code. You can't guarantee where malloc() will store information. Therefore, any code injected into a dynamically-allocated buffer is essentially unreachable without having already executed code, as you can't change a return value to point to it. You still need at least a small static buffer as a springboard.

      Environment variables? Those are arrays on the stack. Not anymore. Put them on the heap with all the other stack-local arrays. I do believe I said -all- stack-local arrays should be eliminated....

      It is much, much more difficult to do any useful exploit if all you can cram data into are stack-local scalar variables. With proper stack construction (insert an illegal instruction between each four byte chunk of the stack), it becomes impossible on most architectures.

      Again, this only applies to arbitrary code exploits. This excludes exploits that merely cause existing code in the executable to execute when it shouldn't (e.g. working around security checks). It does, however, make it really hard to inject arbitrary code, and other exploit types are generally far less interesting unless the app already contains code that calls exec() or something similar.

      --

      Check out my sci-fi/humor trilogy at PatriotsBooks.

    42. Re:An interesting question by Maltheus · · Score: 1

      I think the biggest problem facing us is the inundation of object oriented programming languages. There's very little need to learn the strict mathematics of programming anymore. It is this laziness, and not any particular language, which is the root cause of the problem. Programming environments with sandboxes (ie. Java) are band-aids to a bigger problem.

      Spoken like a true C programmer. The problem is with Utopian programmers who think if we were all uber enough, then there'd be no reason not to use punch cards. All I know is whenever I have worked with different groups on a project, and one group is working on a C component and another group is working on a Java or Smalltalk component, it's always the C component group holding things up endlessly. ALWAYS! And once they get their end done, it's always buggy as hell for years. This is an axiom in any company I've ever worked in. But I see it less and less as managers have started to learn and just don't bother with C projects anymore (at least at the enterprise level).

      C is great for a very small percentage of projects, but you have to jump through hoops to avoid common problems. Most companies just want their projects coded fast and relatively bug free. Documentation is and always will be rare. Turnover in this industry is high. Nobody has time to get up to speed with whatever C scheme you've come up with to avoid memory leaks or buffer overflows. We need them productive, fast. I'm talking real, practical business here, not some college dorm project. We beat our (very tight) deadlines consistently and then our projects sit around waiting to be deployed as we wait for the C coders (we interface with many different companies, so we deal with quite a variety) to finish their ends. It's a boring old tune and I've seen it almost a dozen times this past year alone. Java is not a language for lazy programmers, it's for those who have a shitload to do and can't waste time figuring our why some random piece of memory got overwritten. Fucking barbaric!

  18. Doubtful... by Anonymous Coward · · Score: 0
    There's no such thing as vulnerabilities, all there's is Inteligent Bug.

    Doubtful. Intelligent bug would be a byproduct of intelligent design and I've never heard anyone accuse them of practicing that.

    1. Re:Doubtful... by Leiterfluid · · Score: 1

      That's because it's not accepted as a valid theory in most circles. I think most /.ers believe in Evolution anyway.

  19. Quick everyone turn off images when viewing /. !!! by Anonymous Coward · · Score: 0

    1) To avoid the the new goatse image backdoor
    2) Please type the word in this image.... doh!

  20. But... by Anonymous Coward · · Score: 0

    does it work in Linux?

    1. Re:But... by Fluffy_Kitten · · Score: 0

      it can possibly be emulated in wine... hmmm... i'll get back to you on that

      --
      People who have no sig are cool
  21. typical case of code-based formats by radarsat1 · · Score: 3, Interesting

    The WMF and EMF formats are just basically little programs full of GDI instructions. When you create one, you execute a bunch of GDI calls, with the WMF file as your Device Context. So essentially it's a shortcut-- an "easy" way to create a file format, based on the structure of the operating system's drawing code. I don't know about how the potential exploit works, but at first glance it seems like this is a typical case of designing a file format for "code convenience". Loading the file basically consists of loading a series of instructions and executing them. Now THAT sounds like a good idea! Easy to code for, but also easy to take advantage of. In other words, it's a lazy approach to coding. Lesson to be learned: File formats can be complicated! They must be designed to be a good *format*, not just to make coding easier. The more Microsoft designs its own file formats for each new technology it comes up with, the more we'll see this kind of thing. Better to find out what file formats are already out there, finding one that suits your needs, and supporting THAT, instead of coming up with one on your own. This is a case of re-inventing the wheel, badly.

    1. Re:typical case of code-based formats by cnettel · · Score: 4, Insightful
      Oh, a file format based on instructions, just like, uh, PostScript?

      If you want detailed control over layout, especially with low overhead for rendering, an instruction based approach is quite good. The point is that no GDI call, in itself, should be able to mess things up and simple parameter validation of the WMF input should be enough when spooling the calls.

      (Hey, Postscript is even Turing complete. There's nothing wrong with describing a picture as instructions to a state machine with some rendering primitives.)

      Besides, WMF is 15+ years old now. The availability of formats for vector graphics that matched the features of GDI (while not being expensive, money-wise or performance-wise, to render by GDI) back then was a bit different. The format has never been used much for real files, but quite a lot for clipboard transfer of vector data (Excel graphs and whatnot).

    2. Re:typical case of code-based formats by elsilver · · Score: 2, Interesting
      Loading the file basically consists of loading a series of instructions and executing them. Now THAT sounds like a good idea!

      I'm sorry, but how does this differ from any other vector-based graphics file format? Of course it's the instructions for how to draw the item. Of course they are executed. What else would you want them to do?

      This is also how Postscript and PDF work. Actually post script is more than simple instructions, it is actually a programming language. This is part of why Apple/NeXT chose to use PDF for their native graphic format on OS X, rather than PS as they used for NeXTStep. One of their concerns was, theoretically, printing a file could execute code to do something nasty like reformatted your HD. The commands the PDF contains have more limited access to the environment.

      This is also how the new MS Avalon (I think I've got the right code name) drawing engine works.

      So the moral of the story is not that vector-, or instruction-based graphics formats are bad, but that only a limited set of commands is needed, along with some good sanity checks.

      E.

    3. Re:typical case of code-based formats by radarsat1 · · Score: 1
      So the moral of the story is not that vector-, or instruction-based graphics formats are bad, but that only a limited set of commands is needed, along with some good sanity checks.

      Sorry, I see that I didn't properly express myself. You're right, there's nothing wrong with instruction-based formats. But since the WMF files are direct GDI instructions, they made to be loaded an executed, without proper checking. Not that you can't check them, or shouldn't check them, but that they were originally "designed" so that they wouldn't *need* checking. Which obviously didn't work.

      On another note, the difference between PostScript and GDI is that PostScript is essentially a series of commands being executed in a virtual machine. (an interpreter) Whereas GDI commands are calls to the operating system. The worst you can do to the postscript interpreter is crash it and it stops. The worst you can do to an operating system? well...

      I'm not saying that's the ONLY way to deal with WMF files, I'm saying that due to the way WMF files were "designed", I can imagine it's the most *likely* way they are handled.

      But then, maybe it's just a weak argument. Oh well. :) I was just conjecturing.

    4. Re:typical case of code-based formats by robbak · · Score: 1

      The diference is that pdf/svg files contain instructions for the program made to render them. wmf contains instructions that are passed to the OSes rendering engine. So, a svg file could take over a poorly-written application, and act with that program's permissions.
      A malicious wmf could take over the system, regardless of the application's permissions.

      Just like I've said all along: MS does not know how to achieve privelege seperation.

      --
      Prediction for end of Universe #42: Fencepost error in Quantum_bogosort.cpp
    5. Re:typical case of code-based formats by Kelson · · Score: 1

      Yep, 'cause raster images like JPEG and PNG *never* have this problem!

      (Oh, wait...)

    6. Re:typical case of code-based formats by NutscrapeSucks · · Score: 1

      If you can take over a program, you can issue the same malformed drawing commands which can take over a system. So there's no difference in "privilege seperation" -- the former is just a lot easier to exploit.

      --
      Whenever I hear the word 'Innovation', I reach for my pistol.
  22. Sorta like this quicktime one by MushMouth · · Score: 4, Insightful

    While I hold no place in my heart for microsoft. Quicktime appears to be having a very similar problem. But also remember that the libjpeg and libz also had similar problems exploitable on Linux patched in the last year. Expecting an OS, ANY OS to save you is a bigger security threat than some exploitable jpeg code.

  23. I like this line of Grade-A bullshit.... by HotNeedleOfInquiry · · Score: 4, Insightful

    "We will continue to see this type of vulnerabilities in every major application for the foreseeable future ... It is not just images, but any type of complex file format. This is something that security researchers and hackers have realized to be a weak point in many applications."

    If a programmer is taking the time and effort to interpret a complex file format, why can't he also take the time to validate it.

    --
    "Eve of Destruction", it's not just for old hippies anymore...
    1. Re:I like this line of Grade-A bullshit.... by Anonymous Coward · · Score: 0

      If a programmer is taking the time and effort to interpret a complex file format, why can't he also take the time to validate it.

      Obviously because their manager is breathing down their neck asking for the final build to be done tommorow.

      "Who cares about bugs, they won't see those till they buy the thing"

    2. Re:I like this line of Grade-A bullshit.... by cnettel · · Score: 4, Insightful

      Of course you are right, but you are also ignorant if you don't realize that writing something that seems to interpret every valid file correctly is far easier than writing something that will accept every valid file and reject any invalid file, gracefully. Not to be said that it can't be done or that it shouldn't have been done. Just that it's far more difficult. Even when it's short and seems rather solid. zlib, anyone?

    3. Re:I like this line of Grade-A bullshit.... by HotNeedleOfInquiry · · Score: 1

      Well, I prefer to think that I'm not ignorant.

      That said, if a full validation is not performed, at the very least a bounds check should make sure that a buffer overflow doesn't happen. I would hope you would agree that that's a minimum a good programmer should do.

      --
      "Eve of Destruction", it's not just for old hippies anymore...
    4. Re:I like this line of Grade-A bullshit.... by deepestblue · · Score: 1

      If a programmer is taking the time and effort to interpret a complex file format, why can't he also take the time to validate it.

      If a /.-poster is taking the time and effort to post a comment, why can't the poster also take the time to avoid sexism?

    5. Re:I like this line of Grade-A bullshit.... by Old+Wolf · · Score: 1

      It doesn't have to /reject/ the invalid file. It just has to not allow execution of arbitrary code from an invalid file ! This is not very difficult, these bugs are all the result of sloppy or inexperienced programmers who did not consider all possible inputs to their functions.

    6. Re:I like this line of Grade-A bullshit.... by Anonymous Coward · · Score: 0

      > If a /.-poster is taking the time and effort to post a comment, why can't the poster also take the time to avoid sexism?

      <rolls eyes> <snicker>

    7. Re:I like this line of Grade-A bullshit.... by HotNeedleOfInquiry · · Score: 1

      Sounds like the file format isn't the only thing that needs validating...

      --
      "Eve of Destruction", it's not just for old hippies anymore...
    8. Re:I like this line of Grade-A bullshit.... by Anonymous Coward · · Score: 1, Funny

      IOW--The real problem is LAZY PROGRAMMERS

      Most programmers are fat. Most fat people are lazy (how do you think they got fat in the first place?).

      Solution: HIRE SKINNY PROGRAMMERS

      you think I'm joking but I'm fucking serious! discrimination sucks? LOSE WEIGHT!

  24. Sony Rootkits by Anonymous Coward · · Score: 0

    Now Sony will be able to put a rootkit on your computer without you even putting in a CD!

  25. Guy is from Internet Security Systems by badriram · · Score: 3, Informative

    Internet Security Systems != Microsoft.

    This has nothing really to do with IE. IE here just happens to be a vector. If FF on windows was depending on those libraries to display those image formats they would be vulnerable as well.

    1. Re:Guy is from Internet Security Systems by Khyber · · Score: 1

      Thanks for the correction.

      --
      Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
  26. Re:When writing a parser, length checking is a mus by tomstdenis · · Score: 0, Flamebait

    And similarly you do the same for encoding. First detect the length the data will be, then check, then encode. When testing make sure your "get_length" and "encode" functions return the same length. [if at all possible use the same code].

    But that would be asking MSFT engineers to use "if" statements... that would be ill-advised as it means THEY WOULD HAVE TO KNOW WHAT THEY ARE DOING FIRST.

    Tom

    --
    Someday, I'll have a real sig.
  27. Time to switch to Macintosh by Anonymous Coward · · Score: 1, Informative

    OS X just seems to be bulletproof : no major hacks yet.

    1. Re:Time to switch to Macintosh by evw · · Score: 5, Informative

      You're confusing exploits with vulnerabilities. There have been plenty of vulnerabilities or haven't you been following all the security updates?

      List of security updates for Mac OS X

      Take for example Security Update 2005-008

      This update includes the following components:

      ImageIO
      LibSystem
      Mail
      QuickDraw
      Ruby
      SecurityAgent
      securityd

      Hmm. A security update that touches the ImageIO library?

      p.s. before you flame/mod me into oblivion, I'm a happy Mac OS X user. Yes, Windows has way more bugs and a much worse security record. Is OS X invulnerable? No.

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

      Holy shit, a Mac user that isn't a complete retard. You sir are one of a kind.

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

      Macs are freaking bulletproof. Accept it and move on.

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

      OSX is awesome. So far it seems to have less bugs, it's easy to set up its firewall, and you can use other programs that will do spreadsheets, documents, and email such as...

      Open Office - http://www.openoffice.org/index.html
      Office2004 - http://www.microsoft.com/mac/products/office2004/o ffice2004.aspx?pid=office2004

    5. Re:Time to switch to Macintosh by PsychicX · · Score: 3, Informative

      Normally I'd point out that if MS actually used third party libs for things like PNG and JPEG, they wouldn't have these problems (no more than anyone else, anyway). But since this applies to metafile bitmaps, which basically nobody uses, there's nothing to be done.

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

      Absolutely. Macs simply can't be compromised. And don't give me any of Secunia's theory bullshit: t here's nothing in the wild, and there never has been.

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

      Yeah, Macs totally own, I mean we use them at school to edit short films and we only get the "An unexpected error has occured" maybe 2 or 3 times an hour.. Usually when saving the movie. It's alright though, because rebooting takes a good 5 minutes so we usually dont actually have to spend that much time looking for the right mouse button :)

    8. Re:Time to switch to Macintosh by R3d+M3rcury · · Score: 3, Interesting

      Hear hear! Actually, my favorite was the one in ColorSync. Very scary stuff, because some programs ignore ColorSync profiles, so you might still be able to view your images. But Safari and IE do not ignore them...

      As an aside, this is where the the comment about "Macs have no viruses because they have low marketshare" holds some sway with me. I agree with everyone who says Macs are more secure than Windows, don't get me wrong. Once your code is running, it's much tougher to do anything to spread a virus in the same way that viruses spread in Windows. But part of it is that nobody really does the immense amount of reverse engineering necessary to write a virus or worm based upon an a published vulnerability. While, with Windows, an entire cottage industry has been built to figure that stuff out because there's money in it.

      These things, as with many things in life, do not stem from one reason. Windows has viruses because of poor security. Windows has lots of viruses because of marketshare. Macs have fewer viruses because of better security. Macs have no viruses because of marketshare.

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

      There's money in it? Exactly how, praytell good kind sir, do you get to that conclusion?

      Now if you meant Windows is insecure because there is money in it, then you are right. There is money for AntiVirus Software makers (obvious) and the money Microsoft saves by not investing in securing its operating system. Microsoft is in the enviable position of having an (illegal) monopoly on the market. As such, there is no such need for them to worry about the effect on their marketshare of Windows' insecurities.

      Other OS makers are not in that enviable position. So they take security seriously and actually do the legwork to make their OS's secure.

    10. Re:Time to switch to Macintosh by Viol8 · · Score: 1

      "There's money in it? Exactly how, praytell good kind sir, do you get to that conclusion?"

      Criminal gangs installing spyware , trojans etc for blackmail or other
      purposes.

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

      I juat run as a limited user and access to system files denied by default

      This should be obvious but running as a limited user prevents much unwanted garbage from running or loading , and even if they do, I delete the limited user account and the garbage is gone with it in many cases.
      The point is that it cant pervade the syatem files as easily and unwanted content far easier to remove, if it can't get into the system files

      On a Mac,, many folks do run as a limited user don't they?

    12. Re:Time to switch to Macintosh by lifespan · · Score: 0

      spam old bean...... spam

      --
      -- Howto: Get +5 (1) Whine about M$ (2) Namedrop Gentoo (3) Casually Abuse Mods (4) Namedrop Early Computer Model
  28. complex file formats? by Anonymous Coward · · Score: 0

    The answer is XML.

    No, seriously. Write your XML processor once, do a seriously thorough code audit to prove that no unguarded buffers or pointers are used, and then use XML for all document formats and network protocols where it is at all feasible. Obviously not MPEG, but SVG and OpenDocument and their ilk. Write your file-processing apps in Java or Python or C++ (but with NO pointers, use only iostream libraries and STL objects. No pointers PERIOD!) and the problem will be alleviated for all practical cases.

    1. Re:complex file formats? by FLAGGR · · Score: 0

      Here's a though: make executable files in XML, and you can have the code for an xml parser in xml.

      Then the world would collapse.

      Anyway's, 'tis nothing wrong with pointers, and in alot of cases they are the best solution. If you're too dumb to use them properly, then use some n00b language like Java that protects you from such evils. Yes, even the best sometime forget to do checks and what-not on their pointers sometimes, and those sometimes are the ones that come to bite them in the ass, but for the most part, thumbs up to pointers, thumbs up to c++ and thumbs down to silly languages that protect the coder from their own dumbness.

    2. Re:complex file formats? by Anonymous Coward · · Score: 0

      Actually, pointers suck because of the problem of aliasing. Basically, you can set a pointer to point to any arbitrary memory address you like, which means you have no easy way to analyze code to see if two pointers are using the same block of memory. This throws out a boatload of optimization possibilities.

      This is one of the reasons why C++ recommends using references whenever possible, why C99 introduced the "restrict" keyword, and why most modern languages don't let you diddle with pointers directly to begin with.

    3. Re:complex file formats? by patio11 · · Score: 1
      Yes, even the best sometime forget to do checks and what-not on their pointers sometimes, and those sometimes are the ones that come to bite them in the ass, but for the most part, thumbs up to pointers, thumbs up to c++ and thumbs down to silly languages that protect the coder from their own dumbness.

      I can never figure out what sort of blind machismo animates C programmers that they *know* pointers are inevitably insecure and feel this makes them Manly Men for overcoming the difficulty ("well, most of the time"). The best C coders in the world get bitten in the hindquarters by pointer math, on a regular basis (see the flaw in the libpng, which was old, stable, open-source, well-tested, written by experts, everything you could want for secure software). You wouldn't go to a doctor who said "Screw the diagnostic protocol that relies on wasting fifteen minutes performing checks to verify that you indeed have tuberculosis instead of silicosis of the lungs, I am a MANLY MAN and n00b doctors who don't immediately notice your lack of dialated pupils don't deserve to be in this profession!"

      Thumbs up for "silly languages" that protect ME from the dumbness of the Manly Men who are writing my applications.

    4. Re:complex file formats? by Anonymous Coward · · Score: 0

      No shit. L/RValue access is the only way to be.

      c++ is die hard and not for the careless or reckless. Fucking pissed me off when civ4 guy 'knocked' (didn't use) c++ because it was too hard for them to code properly (Its O.O. what could be easier to manage?). Original civ - rarely crashed, civ2 crashed once in a while, civ3 - unplayabe and unstable as shit, civ4 - fuck it ill run freeciv. If only the UI on freeciv was faster, more functional, and more visually appealing.

      The message I get from most books/articles that Ive read is that simple "smart pointers" (Simple reference counting) are the way to be and the "naked pointers" should be avoided at all costs. But this doesn't teach proper coding skills - it reinforces improper coding skills.

      The coder's code:
      OMG.. THE CODE COMPILED - RELEASE IT NOW!

      To think about:
      Why do you check the sizes of the memory allocation source and destination before writing? You dont, memcpy/strcpy doesn't have 4 parameters.

    5. Re:complex file formats? by Xyrus · · Score: 2, Insightful

      XML == Big fat files.
      Binary == Little compact files.

      Plus add the parser, schema, etc. and you got yourself a big chunk of bloat. A simple RIFF style binary file with GOOD coding practices will be much smaller and more efficient.

      Good example: At a past employer, we wrote software that would generate output data files. They used to be binary, and were roughly 25 to 30 KB in size. Then the whole XML hype set in and our customers just had to have it all in XML. Now output files are between 1 and 2 MB, plus roughly 8 MB of support files (Xalan/Xerces), and they're slower to load. We could have rolled our own, but try justifying the extra cost to the customer.

      Don't get me wrong, XML has its uses. But fast, efficient data storage isn't one of them.

      BTW, there is nothing wrong with using pointers. You just need to know what you're doing. Programmers who write shoddy code with pointers says more about the programmer than the concept.

      ~X~

      --
      ~X~
    6. Re:complex file formats? by FLAGGR · · Score: 1

      Well, okay, what's the alternative? Either an interpreted language which does all the checking real time, which is painfully slow, or a language with a compiler that compiles the safty pads into the final product, which is also slow. The reason pointers are used so often is because they are very useful (sometimes references can be used instead, but not all the time) C++ is the most bare-bones high level language. Compilers are good enough to beat any human writing assembly code now (just read disasembled code, scary) yet the language is OO (but not over the top OO like some languages *cough*java*cough*) and for the most part very human readable (once you get used to it of course) with a clear and extremly flexible syntax (see: the obfustication contest article on the front page ATM)

      Pointers are part of the reason. Pointers are insecure themselves, but their implementation can be. Most (like, 99.9999%) of the time its not a security risk, but sometimes, in complicated code, there's an insecure bit, and it can go unnoticed for forever, until some bitch finds it and your forced to fix it.

      Your doctor-hospital analogy is kind of exaggerated. I don't care if a diagnosis, which my life depends on, takes 15 minutes more to ensure security. However, given the choice of playing BrandNewFPS XVII in C++ and getting a good frame rate, or playing a port of it to some kiddie language that holds your hands and makes every array resizable (aka a linked list), every pointer type thing unoverflowable etc etc etc etc (I'm looking at you, VB and Java) and getting like a tenth of a frame a second (i dont want any Java Isn't Really That Slow, You're Just Imagining It posts, at least I'm slighty on topic) I'd choose the potential risk (see: small potential, pointers are used like crazy and the usage:exploit ratio is very insignificantly tiny) in exchange for the better frame rate.

      Back on topic slightly. What about, in this example, libpng and rendering images? You want your images to load and display very fast, but like EVERYTHING uses libpng and libjpeg etc (at least from the nix perspective) and that is a big bitch if theres an exploit in the code. However, these projects are very open to the public, and exploits won't last long. The last one was a fluke, I bet it was in a very confusing complicated all over the place bit of code and that's why it went unnoticed for so long.

    7. Re:complex file formats? by fireboy1919 · · Score: 1

      Either an interpreted language which does all the checking real time, which is painfully slow

      You don't know what Java does, do you? Modern JVMs use JIT compiling. Think of it like compiling the parts that keep happening. Java is a match for C++ generated code now, and in certain circumstances - such as database business logic - Java usually wins the optimization race, because it can use profiling to figure out how to optimize (unlike something that optimizes at compile-time).

      It does it all inside a sandbox, too. Don't get me wrong: I'm a big fan of C++. It does startup faster, and C++ code is necessarily smaller than java code. But this "its slower" FUD needs to go away.

      --
      Mod me down and I will become more powerful than you can possibly imagine!
    8. Re:complex file formats? by aug24 · · Score: 1
      some n00b language like Java

      Why is it every time I read something like this I am convinced that the writer is little more than a child themselves?

      Give it a while, and you will learn that while it is very useful to understand pointers, it isn't big or clever to use them.

      Justin.

      --
      You're only jealous cos the little penguins are talking to me.
  29. Re:When writing a parser, length checking is a mus by petermgreen · · Score: 1

    imho there are two issues.

    1: when coding with pointers/unchecked length arrays all it takes is one screwup even if you are trying to be carefull. Higher level structures and/or managed code can prevent this but at a cost in performance bloat and in the case of managed code ease of integration with traditional code.

    2: the wmf/emf code is probablly very old from long long before the internet was commonplace. The idea of people deliberately creating image files to bypass security probablly didn't even occour to anyone.

    --
    note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
  30. Ironic. 9x not affected. by Tackhead · · Score: 3, Informative
    > Just imagine, every Windows 98 computer out there probably has this problem too,

    Ironic.

    Non-Affected Software:
    Microsoft Windows 98, Microsoft Windows 98 Second Edition (SE), and Microsoft Windows Millennium Edition (ME)

    - MS05-053 security bulletin

    The usual MS obfuscation for "because we don't support 9x anymore, by definition there are no critical updates for 9x" is to state that 9x is "Not Critically Affected", with a URL to a page that defines "critically affected" in such a way as to exclude 9x.

    "Not Affected", as claimed in MS05-053, is a stronger claim. That's not to say there aren't similar bugs in image-handling in 9x; only that the hole in this notice probably doesn't affect 9x.

  31. ReadOnly OS by nurb432 · · Score: 1

    Sounds like we need to go back to when your OS was mostly in ROM ( like the Ataris for example ).

    At least then if you get exploited, the next time you reboot the exploit goes away.

    --
    ---- Booth was a patriot ----
    1. Re:ReadOnly OS by cnettel · · Score: 1
      Yeah, and you can NEVER patch it. Sorry, but I also kind of like the idea to keep my own data and userland software. I also like to be able to change or update my OS when I choose to. A draconic policy that

      a) won't protect my data against vulnerabilities and

      b) won't let me change the OS

      is

      c) the worst of both worlds.

      Or were you only trying to be funny?

    2. Re:ReadOnly OS by nurb432 · · Score: 1

      No, i was being dead serious. It worked fine for us for many many years.

      Still does, ever hear of the 'embedded market' ?

      --
      ---- Booth was a patriot ----
    3. Re:ReadOnly OS by bobbuck · · Score: 1

      Guys, you can both win. Knoppix. Read-only with updates!

    4. Re:ReadOnly OS by jtorkbob · · Score: 1

      Sounds like a LiveCD to me. If it ain't broke don't fix it. URL:http://en.wikipedia.org/wiki/LiveCD

      --
      AC: Only on slashdot... could the sentence "My hovercraft is full of eels." be moderated "+4, Insightful
    5. Re:ReadOnly OS by nurb432 · · Score: 1

      That is the idea, ( though id prefer a much simpler OS, as its less prone to 'breakage' ) but i was thinking more like solid state ROM for the media.

      Its faster, and no mechanical issues to deal with.

      --
      ---- Booth was a patriot ----
    6. Re:ReadOnly OS by Dan_Bercell · · Score: 2, Informative
      http://www.faronics.com/html/deepfreeze.asp

      A good product for public places like schools/libraries...etc

      If you actualy wanted to use such a product I guess it is possible (although probably annoying) to use it on a personal computer (idealy for kids).

      When I tested this out for a client (public library) I browsed around and obtained several viruses/spyware variants, rebooted and all was fine :)

    7. Re:ReadOnly OS by efuzzyone · · Score: 1

      I will go further. We want an OS which is more than a 'live cd', that is initially install the OS, configure everything the way you want and install all your applications, games etc. Now, once everything is done, burn it into a cd, and always boot from the cd.

      If one wants to install another application boot from the cd, install the application, burn the new image. And there you go.

      I think it is a neat idea, any VCs or clients interested? I have started a new company and I am planning to sell Linux distros, with the above capabilities.

      --
      Creativity uninhibited www.kreeti.com
    8. Re:ReadOnly OS by nurb432 · · Score: 1

      i believe knoppix does this now, if you want a linux variant.

      --
      ---- Booth was a patriot ----
    9. Re:ReadOnly OS by efuzzyone · · Score: 1

      Lot of distros provide live cd, but my idea is to extend the live cd concept by allowing the user to install programs, and then easily burn the new image creating a new live cd. Is that possible? Reading the Knoppix website didn't give any such indication. Thanks.

      --
      Creativity uninhibited www.kreeti.com
    10. Re:ReadOnly OS by nurb432 · · Score: 1

      Yes, that is my understanding. You can store userdata and extend what is installed.

      I fully admit ive not tried it being a BSD guy, but I believe that is possible.

      --
      ---- Booth was a patriot ----
  32. Re:When writing a parser, length checking is a mus by Anonymous Coward · · Score: 0

    Ok, it's 2005, and we still can't handle buffers properly?

    Do you see square wheels on formula 1 cars? Are our aircraft pulled by horses? Do we fuel our powerplants with phlogiston?

    I stand in speechless awe at the inexorable march of computer technology.

    In fact, I give up. I'm going to get a buggy whip to hit my computer with every time it misbehaves.

  33. Every File Format... by istartedi · · Score: 1

    Every file format becomes a programming language in the long run.

    OK, maybe not *every* file format, but most of them. Think about that, and design accordingly from the start. Parse into a VM from the start and write a verifier from the start.

    And no, there isn't a magic bullet. Even the XML advocate who posted before me admitted that wouldn't be an appropriate solution for something like MPEG due to performance concerns. I'm even willing to admit that what I'm suggesting is no magic bullet either; but have some control. Don't wake up one day and realize that somebody can program a 4-function calculator, or something more malicious, in your config file format that started out as... just a config file. Plan for it.

    --
    For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
    1. Re:Every File Format... by k12linux · · Score: 1
      Don't wake up one day and realize that somebody can program a 4-function calculator, or something more malicious, in your config file format that started out as... just a config file. Plan for it.

      How about if you just keep the file's purpose and use as... a config file. If something more is needed use a different file or format that you actually planned out.

    2. Re:Every File Format... by maxwell+demon · · Score: 1
      Every file format becomes a programming language in the long run.

      Actually, the difference between a file format and a programming language isn't that clear (unless you only call turing-complete languages programming languages, then of course there's a clear-cut distinction).
      A simple example: Take a file which uses a simple run-length encoding: If the highest bit is 0, a byte represents just itself; if the highest bit is 1, the lower 7 bits describe a count of how many times the following byte is to be repeated.

      Now, one can say it's a simple comressed file format. OTOH one can also say it's a simple byte code language. A corresponding assembly language could look like this:

      out <value>
      description: output the immediate value ; only constant values in the range 0 to 127 are allowed encoding: 0vvvvvvv where the bits marked v contain the value

      rep <count>, <value>:
      descripion: output <count> times the immediate value <value>; <count> must be in the range 0 to 127 and <value> in the range 0 to 255. encoding 1ccccccc vvvvvvvv where the bits named c contain the count and the bits named v contain the value
      --
      The Tao of math: The numbers you can count are not the real numbers.
    3. Re:Every File Format... by istartedi · · Score: 1

      How about if you just keep the file's purpose and use as... a config file

      I'd like to meet the programmer that can do that under pressure from managers, customers, the community, various other time constraints, and his own desire to "bang something out" quickly. I'd like to meet the programmer that can actually convince people it's worth while to pause development for a few weeks and integrate something new because it'll be better in the long run. I'd really like to meet this person.

      --
      For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
  34. What the hell is it about buffer overflows? by Anonymous Coward · · Score: 0

    Can someone explain to why, out of all possible bugs, buffer overflows seem to be the common cold of security holes?

    Furthermore, What the Hell is so hard about handling this kind of exception that they keep causing such havoc?

    Relatively kowledgeable non-programmers want to know...

    1. Re:What the hell is it about buffer overflows? by petermgreen · · Score: 1

      the main reason is that there is a huge ammount of code written in C there are a variety of (good) reaons for writing code in C but one of its downsides is it makes handling variable length data structures a buisness that can only be done safely by taking great care.

      Since not all programmers care about security (they may have assumed thier lib would only be used with trusted data) and even those that do are imperfect this leads to lots of buffer overflows in C code.

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
    2. Re:What the hell is it about buffer overflows? by HermanAB · · Score: 3, Informative

      The main cause is the C string operators, which traditionally use Null terminated strings. So the potential length of a string is unlimited. In Linux, functions like gets() are (have been) phased out in favour of getsn(), which has an explicit length:
      int getsn(char *cp, int size);

      This has been a huge effort executed using automated search methods and hand coding, to vet enormous amounts of Free code. Consequently the quality of GNU systems have improved dramatically, while the same cannot be said for MS code.

      The problem is that if you overflow a buffer defined on the processor stack, then you can force a new return address into the Program Counter when a routine exits, thus giving the attacker control over the next piece of code to execute. This pice of code is typically part of the string that was used to overflow the buffer.

      --
      Oh well, what the hell...
    3. Re:What the hell is it about buffer overflows? by Rezonant · · Score: 1

      Actually, the same can since some time be said for MS code since they simply deprecated every string handling function of the CRT and introduced the new and improved "Secure CRT" which includes a length parameter on every function, and with more predictable behaviour than the old CRT. Since this is in the latest compiler I assume that any software from MS from now on should be sanitized this way. Of course there are other exploits like integer overflows but they are considerably harder to find and exploit.

  35. When will overflows stop? by G4from128k · · Score: 1
    I can understand that code will always be susceptible to byzantine failure modes that create vulnerabilities -- software isn't perfect and never can be. The lone programmer can't be expected to withstand the onslaught of a horde of black-hat hackers. Nonetheless some categories of faults should be avoidable. For example, buffer overflows, stack overflows, heap overflows should stop being a problem because every programmer should be aware of them and should reuse overflow-proof code constructs.

    Yet I bet that new code will continue to suffer from well-know old vulnerabilities. Perhaps these type vulnerabilities wouldn't occur if anyone who wrote code that is vulnerable to an overflow had their mouse-hand severed from their body. Until truly negligent errors in code carry penalties (for programmer and company), these types of dumb programming errors will continue to create vulnerabilities. Perhaps an analogous code of professional and legal sanctions that governs civil engineering should also govern software. We don't let just anyone build public physical structures, yet we do let anybody build public code structures.

    --
    Two wrongs don't make a right, but three lefts do.
    1. Re:When will overflows stop? by Anonymous Coward · · Score: 0

      Perhaps it is time to seriously consider moving away from a Von Neumann architecture with code and data living in the same memory and to something like a Harvard architecture. It this a magic bullet solution? Of course not; we still have holes and exploits possible but it will help plug that buffer overrun hole. Is this useful in light of all the investment society has made with the current architecture? I dunno...

    2. Re:When will overflows stop? by Anonymous Coward · · Score: 0

      The OS itself shouldn't allow buffer overflows, stack overflows etc.

  36. Practice safe ... listening by weighn · · Score: 1

    Not trying to spread FUD, but couldn't similar exploits can be crafted for mp3 meta-data (ID3) and certain mp3 playing software *cough* iTunes *cough* ?

    --
    Mongrel News all the news that fits and froths
  37. meh by Anonymous Coward · · Score: 0

    It's a big nerd energy black hole! Quick, somebody get the Linux statue so we can make some good use of it!

  38. nothing realy new by Anonymous Coward · · Score: 0

    Hi,

    did still someone believe that MS will change ever?

    CU
    Anonymous Coward

  39. It's a MS thing by TheBillGates · · Score: 1

    Accept it for inner peace.......

  40. Windows 98 OK- Eat Your Heart Out XP Users by Anonymous Coward · · Score: 0
    Windows 98 SE has no problem with this vulnerability. Hell, my 98SE won't even open these files.

    OTOH XP is once again a total cluster-fuck hosed by a simple vulnerability.

    Yet another reason to move to Linux once Win98SE support is terminated.

  41. Getting a certificate is easy by DrYak · · Score: 1

    It very easy to get a certificate to sign online applets/pix/...
    (There are even of account of people havving managed to buy a certificated with "microsoft" in it's name !!!)

    Be sure that, if DRM becomes widespread, the malware creators will be the first to digitally sign everything with such buggy certificate.
    (Just like what is already happenning with ActiveX applets...)

    And meanwhile, lot's of legitimate content will fail, because of lack of signing. (Opensource software that cannot afford DRM certificate, ...)
    No, DRM alone can't bring security, only a false sense of security.

    --
    "Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
  42. The real threat by griffinn · · Score: 3, Funny

    "Microsoft has released Word"

    That is the real threat, my friend.

  43. Re:When writing a parser, length checking is a mus by plalonde2 · · Score: 1

    It's more than just length checking. Anywhere where an offset is generated that will be added to a pointer the offset must be tested for being in range of the target data. That becomes onerous very quickly.

  44. Easy fix! by Anonymous Coward · · Score: 0

    Just stop alowing code to be executed willy nilly off the net. But I forget this is a feature....the real easy fix if to just switch to a real operating system and stop letting others run you. Microsoft will not change the fundimental way in which activeX and their .net nightmare run. In the long run it will be their undoing, especially considering the fact that tax departments and essential services everywhere could be at serious risk. Good for keeping a load of sys admins, and poor joeboy tech staff in jobs for now though. Very soon though something really serious is going to happen and there will be severe financial consequences, now is the time to hone the good old unix and linux skills, the demand will be huge.

  45. In other news by Anonymous Coward · · Score: 0

    one of the marsrovers found yet another rock on mars!

    are we really gonna waste a newspost on every flaw found in windows???
    perhaps put a counter somewhere with the number of flaws found so far, and when you click on it you can see the latest one, would be a lot more convenient :)

  46. Usenet? by mblase · · Score: 1

    Yeah, like viewing an image from usenet.

    Usenet? Is that like a web browser?

    No one ever does that.

    Not since 1998, really.

    1. Re:Usenet? by Antique+Geekmeister · · Score: 1

      Oh, people still view Usenet. But if you do a fast traffic analysis, it's mostly for porn in the alt.binaries groups. Funny, since the flaw is in image viewing, this is exactly what's likely to carry such a worm or virus.

    2. Re:Usenet? by Baloo+Ursidae · · Score: 1
      No one ever [reads Usenet].

      Not since 1998, really.

      Usenet gets more miles today than ever before. As of January 1998, 12 GB of new traffic hit Usenet each day (source: altopia.com). As of March 8, 2005, new traffic volume was up to 1.87 TB per day (source: newsreader.com). Anybody can look this up. The only reason you don't notice it is because many recent Usenet users call it Google Groups, ironically probably not even seeing Google's own timeline of events.

      Fortunately, most of these new users seem to be ignorant of the history and not necessarily becoming a tsunami of stupid like AOL did. If Google did to Usenet what AOL did to Usenet, December 11th would be considered a creepy Usenet parallel to what happened just two months prior to the day, the same year.

      --
      Help us build a better map!
    3. Re:Usenet? by maxwell+demon · · Score: 1
      If Google did to Usenet what AOL did to Usenet, December 11th would be considered a creepy Usenet parallel to what happened just two months prior to the day, the same year.

      What happend on October 11, 2001? I seem to have missed it.
      --
      The Tao of math: The numbers you can count are not the real numbers.
    4. Re:Usenet? by Pope · · Score: 1

      And the new traffic is mostly from Dutch users flooding the living crap out of the .mp3 groups with mislabelled files in the wrong decades, eg. posting the entire collection of Beatles albums in .1980s because that's when the CDs came out. Argh.

      --
      It doesn't mean much now, it's built for the future.
  47. MOD PARENT FUNNY by RedNovember · · Score: 1

    ahh... the horror... *goes crazy* *writes a shell script to delete all .doc*

    --
    "MY APOCALYPTIC TENOR HAS NOT BEEN DISPELLED!" - T-Rex, qwantz.com
  48. The Lusers Were Right All Along by ObsessiveMathsFreak · · Score: 1

    I remember people back in 1998 smugly telling me as they surfed the net over my shoulder:
    "You know if you view an image with a virus, it'll infect your computer"

    I vividly remember openly scoffing at their remarks and explaining in detail why what they were proposing was completely impossible.

    And now they were right all along. Do I have to email out apologies?

    --
    May the Maths Be with you!
    1. Re:The Lusers Were Right All Along by Kelson · · Score: 1

      Hey, I remember the days when I had to keep explaining to people that you couldn't get a virus just by reading an email, that you *had* to open an attachment to get infected. How times change...

  49. More of the same by quantum+bit · · Score: 1

    I wonder if they'll "fix" any of these the same way they "fixed" the xbm overflow in IE -- by removing support for the format completely.

    Oh well, because of that smooth move, I managed to convert someone to firefox who otherwise would have never considered it...

  50. Re:When writing a parser, length checking is a mus by Anonymous Coward · · Score: 0

    And oddly enough, the obvious recursive function to do this is EXACTLY what caused the ASN.1 parsing vulnerabilities in Windows, pretty much demonstrating why ASN.1 is a How Not To Design Your Format format.

  51. gifs by Anonymous Coward · · Score: 0

    You can create a gif in a folder, and upload the file to someone's php forums or game. Then you back delete the gif in that folder. In it's you write some code and change the extension back to gif. Now, when they look at that lil booger bam your code is running. Welcome to the internet. This will effect Linux and Windows alike.

  52. Very dangerous for surfers by Anonymous Coward · · Score: 0

    Once this virus gets into pr0n sites, it could be the end of the world as we know it. =O

  53. Re:When writing a parser, length checking is a mus by SilverspurG · · Score: 1
    The idea of people deliberately creating image files to bypass security probablly didn't even occour to anyone.
    At first glance I'm likely to be sympathetic to this line of reasoning. Then my strict education kicks in.

    If they can't code it right then maybe they should be serving french fries.
    --
    fast as fast can be. you'll never catch me.
  54. This is probably going to get modded as funny, but by Patchw0rk+F0g · · Score: 3, Interesting

    ...I've been trying to get porn flash ads off MSNBC and Yahoo for weeks now, at home, when at work the sites are just fine. Spyware, right? Well, Spybot, Norton, and AdAware say... a resounding "No". Nothing there. Yet the front page of MSNBC and my Yahoo mail still have ads for some guitar software, daBoink.com, and some fucked-up screensaver rotating with nauseating frequency.

    Oh, and before you ask... twice a week virus scans, two noted spyware blockers, and a reliable firewall. How reliable? Shit, /. port-scans me every time I freakin' post!

    Okay, now go on and say it... all together now... "Serves... YOU... ......."

    --
    When the going gets weird, the weird turn pro. ~~ Hunter S. Thompson
  55. I've got the solution! by SeaFox · · Score: 3, Funny

    Only use plain text email and turn off all image loading in Internet Explorer!

    Not only will this stop the spread of viruses, it will drive hundreds of thousands of noobs off the internet. Usenet will be stored to it's former glory and AOL will go out of business. Marketshare of Linux and MacOSX will skyrocket and peace and balance will be restored to the Force!

    1. Re:I've got the solution! by crazyjimmy · · Score: 1

      Yeah, but you'd still be using IE

  56. This is so five years ago by pestilence669 · · Score: 1

    Believe me, you don't need to get *THAT* hardcore with imaging flaws to take over a Windows machine.

  57. My wife always told me... by Anonymous Coward · · Score: 0

    ...length does not matter! :(

  58. Adblock filters by TopSpin · · Score: 3, Interesting

    Add *.wmf and *.emf to your adblock filters (I presume if you browse with Windows you're using Firefox and Adblock, otherwise...) These formats hardly ever appear on the web. If you see one, it's probably an exploit.

    --
    Lurking at the bottom of the gravity well, getting old
  59. Re:When writing a parser, length checking is a mus by Anonymous Coward · · Score: 0

    Having written ASN.1 parsers/emitters, I'd have to say this isn't the best example to illustrate an otherwise valid point about sanity-checks.

    The ASN.1 format is entirely dependent on accurate data-length values - if the length attribute of an element doesn't match the actual element size, the parser will collapse, since it will attempt to interpret the byte at tag+length-word+data-length as the next 'tag'.

    As a consequence of this, ASN.1 reader/writer code tends to be very 'length-aware' by nature. Buffer overflow exploits are the least of your problems if you get the lengths wrong on ASN elements - the larger problem will be that your ASN.1 file will be unreadable by any ASN.1 parser.

    I wish I could come up with a better example than ASN.1 ...

  60. sadly, I don't recall libpng or ungif being closed by DaedalusHKX · · Score: 1

    Which IS what ALL M$ libraries are... they only open if you provide re$ource$ to Micro$oft... and sadly, not all of us have... ummm... the "re$ource$" to donate to the not so gentle giant...

    ~D

    --
    " What luck for rulers that men do not think" - Adolf Hitler
  61. I think you meant to write... by Anonymous Coward · · Score: 0

    ..."Windows flaws puts image handling at risk."

  62. what is wrong with that code by r00t · · Score: 2, Informative

    You might hit unwritable (possibly unmapped or kernel) memory before your uninitialized pointer overflows the stack. This makes the backdoor very unreliable. Also, on a 64-bit machine, you might have to transfer many terabytes of data.

    Fixed code:

    void echo(void) { char S; char *s= gets(s); puts(s); putchar('\n'); }

    Note that the fixed code neatly avoids many stack protection mechanisms by not using a normal array. An improvement would be to use a more interesting struct to hold the data, with enough room to hide the backdoor from testers.

    Uh, this was intended to be a backdoor, right? You didn't say what the code was expected to do.

    1. Re:what is wrong with that code by UncleFluffy · · Score: 1

      Shouldn't that be "gets(&s)"? And puts() appends a '\n' automatically :)

      But yes, you'd pass :)

      Next question would be the good old "write strrev()"

      --

      What would Lemmy do?

    2. Re:what is wrong with that code by r00t · · Score: 1

      The code was different when I posted it.

      As usual, Slashdot eats my punctuation even if I use "Plain Old Text" mode.

      WTF is with that? It's not a real "Plain Old Text" mode if it doesn't properly handle an ampersand. If I had chosen HTML mode, sure, I'd properly have responsibility for that myself. All I want is a working "Plain Old Text" mode!!!

      And, while I'm at it, what the heck is Extrans? If THAT does what I want, then why isn't it called "Plain Old Text"?

    3. Re:what is wrong with that code by UncleFluffy · · Score: 4, Funny

      The code was different when I posted it. As usual, Slashdot eats my punctuation

      Yeah, yeah, "the dog ate my homework". Heard it before ... ;-)

      --

      What would Lemmy do?

  63. how? by r00t · · Score: 1

    Running out of stack space?

  64. The truely funny (read: sad) thing is... by thecampbeln · · Score: 1
    The Anna Kournikova "image" virus can now be named "AnnaKournikova.jpg" instead of "AnnaKournikova.jpg.vbs"... what a difference 4 years makes...

    Good thing SquirrelMail removes all inline images from my email!

    --
    "1984" was ment to be a warning, not a guidebook. You hear that Kim Jong-il!? BushCo?!
  65. Image handling exploits can be good, too by UfoZ · · Score: 2, Informative

    Maybe it's a bit ironic that sometimes exploits like this can be considered "good" - for example, just recently a buffer overflow vulnerability in libtiff opened up the way to running homebrew code on the PSP 2.0 firmware. Of course, Sony patched up the hole in the next update.

    Fortunately, PSPs aren't getting remmotely compromised over the internet (yet?...) Windows boxes are a whole different story, though :)

  66. Re:This is probably going to get modded as funny, by efuzzyone · · Score: 1

    Use mozilla firefox and install adblock and flash blocks. They will get rid of all flash and ads, which you don't want.

    --
    Creativity uninhibited www.kreeti.com
  67. The greatest threat to Windows... by Billosaur · · Score: 1

    ...is in booting up your machine.

    --
    GetOuttaMySpace - The Anti-Social Network
    1. Re:The greatest threat to Windows... by cyber_rigger · · Score: 1

      ...is in booting up your machine.

      ......with Linux

  68. Re:Avoid useless Adblock filters by adtifyj · · Score: 2, Interesting
    Mozilla won't download these files from the internet anyway.
    Bug 88691 : [RFE] ability to show Windows Metafiles (for windows only builds) referenced by <IMG> is desired

    ...
    Why do we need to add Windows Metafiles support to the imagelib? Nobody uses it on the net. WONTFIX!
  69. Is Linux vulnerable? by 123xyz · · Score: 0

    I am curious: how about Linux graphics-handling libraries? Has anyone seen any vulnerabilities to this issue in them?

  70. Automatic updates already came in for this one... by Radi-0-head · · Score: 1

    I received an automatic update notification for this very issue just a couple of hours ago. Applied and restarted. Until the next update...

  71. Speaking of STD's by ImaLamer · · Score: 1

    I've always said surfing the web with IE is like going around sticking your dick in people without a rubber... eventually you are going to get something.

    (off-topic, forgive me...)

    Nothing is safe anymore. Sex became scary and now looking at porn is going to give me a virus or some other sort of infection that isn't easy to clear up.

    Sheese

  72. Every major application? by AntiCopyrightRadical · · Score: 1

    I called it.

    [If] current attitudes and results about development continue, within 10 years new coders will be hearing that "It is impossible to write complex software that isn't subject to running arbitrary code."

    Sadly, this came true sooner than I thought.

    --
    Abolish Copyright. Restore Freedom.
  73. Re:This is probably going to get modded as funny, by HermanAB · · Score: 1

    Firefox adblock *.swf La voila, hamba flash...

    --
    Oh well, what the hell...
  74. Security issues by Anonymous Coward · · Score: 0

    When will Slashdot report on Linux's security problems?

  75. Windows Image Handling by oztiks · · Score: 1

    Has always been badly handled!

  76. Re:When writing a parser, length checking is a mus by Anonymous Coward · · Score: 0

    That's why you use a databuffer class. Leave the pointer arithmetic alone.

  77. Windows kernel buffer overflow for .BMP fixed? by Animats · · Score: 1

    Did the kernel buffer overflow in the .BMP/.RLE decoder ever get fixed? I was amazed to find that code in the NT/Win2K kernel.

  78. because it's free of vulnerabilities, right? ;) by cwerdna · · Score: 1

    I count 41 in the last month for instance at http://www.us.debian.org/security/. Feel free to check other distros.

  79. Data can Execute Code. by rawg · · Score: 1

    I just don't get it. How does a data format have the ability to execute code? I know that they cause a buffer overflow, but why isn't all the buffer overflows fixed by now? I mean, it's been years now that we all have been told about them. You would think that by now everything has been sanitized...

    --
    The above is not worth reading.
    1. Re:Data can Execute Code. by Anonymous Coward · · Score: 0

      char buffer8[8];
      char idunnostr[32000];
      strcpy(idunnostr, "I don't know");
      memcpy(idunnostr[13], infamousstackattackcode);
      strcpy(buffer8, idunnostr);
      printf("%s",buffer8);
      //output:
      I'm owned! 10billion more to come

  80. Re:This is probably going to get modded as funny, by advocate_one · · Score: 1

    you're going through a proxy filter at work... that's removing the crap before it gets to your machine...

    --
    Donald 'Duck' Dunn: We had a band powerful enough to turn goat piss into gasoline.
  81. Re:When writing a parser, length checking is a mus by Steeltoe · · Score: 1

    It did occur to people. But the mindset was just not there to fix it. People are generally happy if things are working. To go the extra mile of paranoid security-checks, requires a mindset and to put security high on the agenda.

    I remember back in the early 90's I was curious if pictures could actually contain viruses. I always assumed people would code in checks to prevent overflows, so I didn't think more about it. Assumptions is ignorance, that was my fault.

  82. Re:This is probably going to get modded as funny, by Patchw0rk+F0g · · Score: 1

    you're going through a proxy filter at work... that's removing the crap before it gets to your machine...

    Actually, no. The ads just change. At work, we're back to the peacock with the 50 state names rippling all over its annoying ass. Actually, I think I prefer the blonde with the big wazooms. I'm not buying from either company, so why not have an attractive ad for a change?

    --
    When the going gets weird, the weird turn pro. ~~ Hunter S. Thompson
  83. Been patched for, RTFA "AntiMicrosoft" crew here by Anonymous Coward · · Score: 0

    This was patched for, yesterday 11/08/2005, here:

    http://www.microsoft.com/technet/security/bulletin /ms05-nov.mspx

    Get with it, slashdot article submitters, & RTFA!!!

    APK

    P.S.=> Enough "anti-microsoft" F.U.D. already, @ least print the 'flaw' was patched for, & read the damn article... One for the Linux crew, here:

    http://linux.slashdot.org/article.pl?sid=05/11/08/ 140203&tid=220&tid=106

    "Linux Lupper.Worm In the Wild"

    And yes, the flaw for this worm having an opening is unique to Linux & its variants (in an app that runs on it)... apk

  84. Blame programming languages for that, though. by master_p · · Score: 1

    Indeed, it's easier to write code without testing all the invalid cases.

    But it is mostly the fault of the programming language used that discourages programmers for testing the invalid states of the program.

    Take C, for example: there is no way to specify a logical type consisting of certain float values, for example. There is no way to specify a subtype of short that takes values 0, 1 and 2. There is no way to specify that a bitmap file is a header, followed by a 2d array of bytes with dimensions specified in the header. There is no way to make the GDI command Ids used in the WMF files a type!

    C++ and Java continue this trend by sacrifising type correctness for language simplification. At least C++ gives you the means to manually code strong value types...

    1. Re:Blame programming languages for that, though. by praxis · · Score: 1

      I take it you have not been writing much C. Everything you describe above is possible. C does not do anything to discourage one from testing for invalid states. Did you perhaps mean that--unlike certain other languages--C does nothing to enforce or encourage one to validate the state?

    2. Re:Blame programming languages for that, though. by master_p · · Score: 1

      take it you have not been writing much C. Everything you describe above is possible.

      Having written the only known copying & defragmented multithreaded garbage collector for C that's under 1500 lines of code which is faster than Java, I believe your statement is wrong.

      Anyway, you can't do logical types in C. Can you say in C that a pointer is never null? or that a pointer takes only three possible values? or that an array takes size from a field in a lower address? or that a short can be an enumeration? can you do float enumerations in C? sets? recursive types? union types? uniqueness types?

      The answer is simple: you can't.

    3. Re:Blame programming languages for that, though. by praxis · · Score: 1

      I wasn't talking about syntatical sugar. It was speaking to the fact that C is turing complete. While it's true that languages differ in the paradigms they enable and the paradigms they restrict, saying that because you can not have a particular structure available in another language does not mean that the equivalent cannot be accomplished. I do not see what having written a garbage collector for C has to do with any of this.

  85. Efficiency DOES matter by Viol8 · · Score: 1

    "With 3.0+GHz machines, what does it matter anymore?"

    Coders like you are the reason we now NEED 3ghz machines to do anything
    useful with bloatware like windows. You accuse other programmers of
    being lazy then say that making a program efficient is unimportant.
    Hello??! Pot , this is kettle calling!

    "for why they've violated strict logic flow is always,"

    Most bugs are nothing to do with violated logic flow and everything
    to do with simple human error. Until The Perfect Human is invented
    then bugs (if still written by humans) will always be with us.

  86. Sure you can view them on old computers. by Viol8 · · Score: 1

    Just not old PCs (unless they're running Linux, BSD etc). Still, you
    pays your money , you takes your choice. Want Windows? Then put up
    with the bugs,

  87. Re:When writing a parser, length checking is a mus by virtual_mps · · Score: 1
    Having written ASN.1 parsers/emitters, I'd have to say this isn't the best example to illustrate an otherwise valid point about sanity-checks.

    Given the fact that there have been major parsing errors in common ASN.1 libraries I'd say that it's a very good example.

    As a consequence of this, ASN.1 reader/writer code tends to be very 'length-aware' by nature. Buffer overflow exploits are the least of your problems if you get the lengths wrong on ASN elements - the larger problem will be that your ASN.1 file will be unreadable by any ASN.1 parser.

    Ah, you're commiting the classic error of "it handles valid input properly, so it must be ok".
  88. image handling flaw in windows by thabigdada · · Score: 1

    just handling windows is a flaw!!!

  89. Money in vulnerability by Merdalors · · Score: 1
    There's money in it? Exactly how, praytell good kind sir, do you get to that conclusion?

    Spyware that tracks & reports surfing habits. The marketing data is worth millions. Not that they're interested in where you, specifically, are going, but rather what sites are popular.

    --
    Slashdot entertains. Windows pays the mortgage.
  90. No. No. No. by Just+Some+Guy · · Score: 2, Insightful
    As an aside, this is where the the comment about "Macs have no viruses because they have low marketshare" holds some sway with me.

    Apache hosts vastly outnumber everything else combined. Postfix/Sendmail/Qmail/Exim probably have 90% of the email server market. There are many more installations of MySQL than MSSQL. And yet, how many worms have you seen roaring through the Internet unstopped that affect those applications? By any count, relatively very few.

    And yet the bad guys, who even have the full source code to each of those, haven't had as much luck attacking Unix-based systems as Windows, even though Unix basically owns the Internet server market. So much for the "market share == vulnerability idea", even though the prize for owning a Unix server on a fat pipe is much greater than owning a Win95 box on a dialup.

    This hypothesis gets trotted out every time the subject comes up, but it really needs to die. The overwhelming amount of evidence supports the theory that solid design is the path to good security - obscurity doesn't seem to have much to do with it.

    --
    Dewey, what part of this looks like authorities should be involved?
    1. Re:No. No. No. by R3d+M3rcury · · Score: 1

      Sigh. You need to pay attention. I'll say it again: marketshare is not the only element of the equation. Better code and better security procedures are a big part of it. I won't disagree. But to say that marketshare and obscurity--both definitions--don't fit into the equation is not seeing the forest through the trees.

      Again, first we have the vulnerability. Parts of Mac OS X have vulnerabilities. So do parts of Windows. So what makes Windows different from Mac OS X?

      One element is what you can do with a vulnerability. Under Windows, if you can get code to run, you can quietly take over the machine. The user of the machine will never be aware that they've been turned into a zombie. With Mac OS X, this is far more difficult or impossible. The user has to be involved, which requires some social engineering. So, if there's a bug in, say, some image libraries, I can turn a Windows machine into a zombie. If there's a bug in the same image libraries in Mac OS X, there's not a whole lot I can potentially do and remain undiscovered. So one element which makes Windows different from Mac OS X is what I can do with a vulnerability. If there's less I can do, there's less interest in exploiting the vulnerability.

      That's where the better security comes in.

      However, there's also some other elements which you're ignoring. One is obscurity. I mentioned "both definitions." If you look up obscure in the dictionary, you'll see that it means something that is not common and something that is hidden. To tackle the "hidden" part first, this has to do with the amount of work necessary to reverse engineer a patch. Again, like above, it's the amount of work I have to do for the gain I can get. If I spend a month reverse engineering a patch to figure out what it fixed and all I can do with it is pop up a dialog box in the user's face that says, "You suck", it's not really worthwhile.

      Brief tangent: Also, if I spend a month reverse-engineering a patch, I think it's more likely that--as a percentage--more people have applied the patch on the Mac side than on the Windows side. Personal opinion, this has to do with trust. When Microsoft announced Windows Auto-Update, the world was aghast. "Microsoft will be scanning my hard drive, finding all my pirated software, and calling lawyers! I don't want Microsoft auto-updating anything!" When Apple had the same thing in Mac OS X, people said, "Whew! Now I won't have to worry about security issues." People, generally, trust Apple. They don't trust Microsoft. Again, by the time I have my evil payload ready to roll, most of my intended victims will be protected against it. Less incentive to put in the effort in the first place.

      Back to "obscurity", the second element is obviously how prevalent the machines are. You mention "Unix-based systems", but which one? Are we talking linux, Solaris, Mac OS X, IRIX, OpenBSD, or NetBSD? Also, remember the hardware underneath a "Unix-based system" may be Intel, POWER, PowerPC, SPARC, or MIPS. Heck, that problem alone would make me want to stay away! I need to have the hardware and software combinations in order to do the hack.

      The final element is how the machines are being used. There are more Unix-based servers than Windows based servers, but there are more Windows-based clients than all platform-based servers. If I'm trying to build a botnet, I don't have that much interest in servers. If I'm trying to steal credit card numbers, I can either steal them from the server or the client. The client is much easier to hit and I can get lots of numbers through volume. I can get lots of numbers by hitting one server, but it'll be a lot more work. To draw a so-so analogy, is it better to rob 50 small-town bank branches or to rob Fort Knox? Robbing Fort Knox will get you more money than the 50 small-town banks, but it will be much more difficult.

      That's why when people trot out the statistics, I have to question the interpretation. Could the lack of viruses for "Unix

  91. After more than a year, KB896424 finally fixes... by Anonymous Coward · · Score: 0

    http://sylvana.net/test/AP4.jpg , which would crash IE.

  92. Input Checking is basic Freshman CompSci by billstewart · · Score: 1
    I took CS100 Freshman Computer Science Course about 30 years ago, and among the first couple lessons they taught us, besides structured programming, commenting our code thoroughly, and how to print "Hello World" on punch cards, was Never trust your input and always verify it before using it, and any programming exercises we did had to use the professor's input deck which would be sure to check for off-by-one boundary errors, wrong data types in fields, and more malicious stuff. Off-by-one problems are usually programming errors, though sometimes they're requirements definition errors, but incorrect input, wrong types, and scrambled input are things that real-world input normally contains, and malicious input is not only something you should *expect* crackers to hand to any program that'll expect it, you can also expect CS professors to hand you to test whether your program really got all the critical concepts.

    It really irks me that supposedly professional companies sell software that doesn't follow basic lessons like that, especially for the standard libraries they provide so everybody's programs can avoid writing special file format parsers from scratch.

    Some of this is because too many people still write in C when they're not good enough to do it competently, and the companies they work for aren't making sure their code is properly reviewed, and they're letting them use a language that lets you shoot yourself in the foot. Don't get me wrong - C is still my favorite programming language, small, clean, elegant, and obvious, but most people shouldn't be allowed to use it.

    --

    Bill Stewart
    New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
  93. Managed code isn't enough by billstewart · · Score: 1
    Managed code means that before you shoot yourself in the foot, you wrap your foot in a baggie to make sure that blood won't get on the floor. It's certainly a good start, and it keeps the floor clean, but basically it doesn't do much for you except have an exception handler print out a message saying "this.status == dead, Jim!" and send a garbage collector to pick up your nicely bagged corpse from the floor.

    In practice, you need to do more than that - even if it's just printing a more informative error message or (more typically) rejecting the bad input file and asking the user for another one.

    --

    Bill Stewart
    New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
  94. Do the math by cyber_rigger · · Score: 1

    If debian has 1 vulnerability per day
    considering the fact that debian has 17,000+ packages
    that would average 1 vulnerability per package every 46.5 years.

    Most users only use a small subset of these packages.

    Yes, debian has relatively low occurance of vulnerabilities
    considering the volume of software involved.