Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Windows Operating Systems Software Security

Image Handling Flaw Puts Windows At Risk 287

Posted by Zonk from the don't-click-there dept.
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.'"
This discussion has been archived. No new comments can be posted.

Image Handling Flaw Puts Windows At Risk More

Image Handling Flaw Puts Windows At Risk

Comments Filter:

  • Huh? (Score:5, Funny)

    by Anonymous Coward on Tuesday November 08, 2005 @06:14PM (#13983531)
    Windows wasn't open to spyware and viruses before?

  • DUPE (Score:4, Funny)

    by 42Penguins ( 861511 ) on Tuesday November 08, 2005 @06:14PM (#13983532)
    This vulnerability is a dupe!
    Windows has already had an image handling flaw!
    Oh, it's Windows. False alarm.

    • Re:DUPE (Score:2, Informative)

      by Anonymous Coward
      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.

  • Critical Bug? (Score:5, Insightful)

    by geomon ( 78680 ) on Tuesday November 08, 2005 @06:14PM (#13983535) Homepage Journal
    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.
    • 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.
    • No, it also becomes a problem when/if the patch breaks something else, like it did with one of last months security fixes.
      • 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

    • Re:Critical Bug? (Score:5, Funny)

      by conJunk ( 779958 ) on Tuesday November 08, 2005 @06:31PM (#13983698)
      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...

      • Re:Critical Bug? (Score:3, Interesting)

        by Taladar ( 717494 )
        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).

    • Re:Critical Bug? (Score:4, Informative)

      by shmlco ( 594907 ) on Tuesday November 08, 2005 @06:41PM (#13983777) Homepage
      Of course, we also have recent announcements of imaging bugs and vulnerabilities in Apple's QuickTime [zdnet.com] that can allow machines to be hijacked. As such, I gather *nix systems can and do have similar problems.

      • Re:Critical Bug? (Score:3, Informative)

        by geomon ( 78680 )
        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.
    • 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 trust Microsoft [...]

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

    • Yeah, like viewing an image from usenet.

      Usenet? Is that like a web browser?

      No one ever does that.

      Not since 1998, really.
  • This is why we need more managed code.

    • An interesting question (Score:5, Insightful)

      by ThePyro ( 645161 ) on Tuesday November 08, 2005 @06:29PM (#13983679)
      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.
      • 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.

        • Re:An interesting question (Score:5, Funny)

          by cbiltcliffe ( 186293 ) on Tuesday November 08, 2005 @08:41PM (#13984565) Homepage Journal
          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.

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

        • 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 cre

          • Re:An interesting question (Score:5, Insightful)

            by SilverspurG ( 844751 ) * on Tuesday November 08, 2005 @07:45PM (#13984261) Homepage Journal
            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.

            • 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.

              • 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?)
              • I'm not a programmer, but I'm interested in the answer. Can you elaborate?
              • 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 h

          • 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 impleme

      • 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).
    • 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'.

  • Practice safe image viewing folks! (Score:5, Funny)

    by nizo ( 81281 ) * on Tuesday November 08, 2005 @06:15PM (#13983543) Homepage Journal
    Or your computer could get an STD (Screenally Transmitted Disease) from viewing pornographic images.

  • Ack! (Score:5, Funny)

    by rubberbando ( 784342 ) on Tuesday November 08, 2005 @06:16PM (#13983549)
    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?!!

    • Re:Ack! (Score:2)

      by nizo ( 81281 ) *
      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 :-(

  • So, Windoze merely has an image problem? (Score:2, Funny)

    by Anonymous Coward
    It's not really a fundamental flaw?

    • 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.

  • MSN Messenger felled by this months ago (Score:5, Interesting)

    by saskboy ( 600063 ) on Tuesday November 08, 2005 @06:19PM (#13983574) Homepage Journal
    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.

    • Re:MSN Messenger felled by this months ago (Score:5, Informative)

      by webzone ( 924183 ) on Tuesday November 08, 2005 @06:39PM (#13983761)
      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
      • 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.

    • Ironic. 9x not affected. (Score:4, Informative)

      by Tackhead ( 54550 ) on Tuesday November 08, 2005 @06:52PM (#13983870)
      > 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 [microsoft.com] 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.

  • Of Course (Score:3, Interesting)

    by NanoGator ( 522640 ) on Tuesday November 08, 2005 @06:21PM (#13983596) Homepage Journal
    Of course, I think the developers who left these vulnerabilities open should be financially responsible for the damage this may cause.

    • Would you expect the same to apply to the authors of, say, libpng? Or libungif?
      • 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.
    • 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.

    • Re:Of Course (Score:2, Interesting)

      by Mistshadow2k4 ( 748958 )

      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 [babsonfreepress.com]

      Imagine it this w

  • When writing a parser, length checking is a must (Score:5, Interesting)

    by Harry Balls ( 799916 ) * on Tuesday November 08, 2005 @06:22PM (#13983610)
    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.

    • 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 t
    • 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.
  • 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.
  • 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.

    • Re:Another brownie point for the cause of DRM? (Score:5, Insightful)

      by plover ( 150551 ) * on Tuesday November 08, 2005 @06:33PM (#13983709) Homepage Journal
      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.

      • > 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

    • 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, .

  • phishy... phishy... (Score:3, Insightful)

    by lcde ( 575627 ) on Tuesday November 08, 2005 @06:27PM (#13983658) Homepage
    '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.

    • Re:phishy... phishy... (Score:2, Insightful)

      by Senzei ( 791599 )
      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.

  • typical case of code-based formats (Score:4, Interesting)

    by radarsat1 ( 786772 ) on Tuesday November 08, 2005 @06:36PM (#13983735) Homepage
    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.

    • Re:typical case of code-based formats (Score:5, Insightful)

      by cnettel ( 836611 ) on Tuesday November 08, 2005 @07:04PM (#13983980)
      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).

    • 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 cho

      • 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

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

      (Oh, wait...)

  • Sorta like this quicktime one (Score:5, Insightful)

    by MushMouth ( 5650 ) on Tuesday November 08, 2005 @06:36PM (#13983736)
    While I hold no place in my heart for microsoft. Quicktime [com.com] 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.

  • I like this line of Grade-A bullshit.... (Score:5, Insightful)

    by HotNeedleOfInquiry ( 598897 ) on Tuesday November 08, 2005 @06:37PM (#13983741)
    "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.

    • Re:I like this line of Grade-A bullshit.... (Score:5, Insightful)

      by cnettel ( 836611 ) on Tuesday November 08, 2005 @07:07PM (#13984004)
      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?
      • 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.
      • 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.

    • 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?

  • 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.
    • 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?

  • 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; bu

  • 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

  • The real threat (Score:4, Funny)

    by griffinn ( 240043 ) on Tuesday November 08, 2005 @07:22PM (#13984124)
    "Microsoft has released Word"

    That is the real threat, my friend.
  • 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?
  • 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...

  • This is probably going to get modded as funny, but (Score:3, Interesting)

    by Patchw0rk F0g ( 663145 ) on Tuesday November 08, 2005 @07:59PM (#13984348) Journal
    ...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... ......."

  • I've got the solution! (Score:4, Funny)

    by SeaFox ( 739806 ) on Tuesday November 08, 2005 @07:59PM (#13984351)
    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!

  • Adblock filters (Score:4, Interesting)

    by TopSpin ( 753 ) * on Tuesday November 08, 2005 @08:17PM (#13984447) Journal
    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.

Slashdot Top Deals

To communicate is the beginning of understanding. -- AT&T

Close