Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Security Windows

MS Critical Patch Fixes 8 Vulnerabilities 202

nandemoari writes "A hole allowing hackers to take control of Microsoft Exchange was just one 'critical' issue the Redmond-based company promises it has fixed with a patch correcting a total of eight vulnerabilities in its programs, including the Internet Explorer browser, Office, and its SQL Server. Three of the eight vulnerabilities patched yesterday were marked 'critical.' The most concerning is an issue with Exchange that would allow attackers to take over an Exchange server by simply forwarding a carefully crafted message to a corporate mail server. Microsoft has admitted that the vulnerability can be exploited when a user opens or previews an email in the Transport Neutral Encapsulation Format (TNEF)."
This discussion has been archived. No new comments can be posted.

MS Critical Patch Fixes 8 Vulnerabilities

Comments Filter:
  • by segedunum ( 883035 ) on Wednesday February 11, 2009 @11:41AM (#26814273)
    Many people would love to outsource management of Exchange server, and it's even better if someone wants to do it for free.
    • Why? If a company with in house IT can't administer an Exchange server, there's something seriously wrong with their staff selection.
      • Re: (Score:3, Interesting)

        Maybe their budget doesn't stretch so far as to be able to employ 1 guy to do nothing but manage a mail server.

        Exchange is a big pain in the ass, and it doesn't scale very well. I hate it, and all I have to do with it is keep it from ever touching the web directly.

        • by DarkOx ( 621550 )

          E2k7 is a major leap forward in terms of scalability and touch requirement's. Its probably easier to architect correctly as well compared with e2k3. E2k3 and prior could actually scale pretty well but you had to be an exchange guru to do it right and spend a lot of energy managing the environment. They also worked ok for small single server shops out of box with little touch. It was the vast space in the middle they handled poorly.

          E2K7 strikes me as something that would be a bit of bare for anyone not a

          • Re: (Score:3, Interesting)

            Let me start by saying that I never want to see the words "bare" and "it professional" in the same sentence. Ew. Ew. Ewwwwwwwwwwww.

            That being said, I'll acknowledge that Exchange is actually improving pretty dramatically between releases. Even 2k3 is so far ahead of earlier Exchange releases as to be almost unrecognizable. We run about 300 users on a pretty small hardware footprint, and, provided you run everything through an antivirus before you send it to the users, it all works with little supervision.

            I

  • Is it that easy? (Score:5, Interesting)

    by UnknowingFool ( 672806 ) on Wednesday February 11, 2009 @11:44AM (#26814317)
    I don't know anything about Exchange but you mean to tell me that someone sending an email to an Exchange server can allow it to take over the server? It's one thing for hackers to rely on social networking and fool a user into executing an attachment. It's another thing to be able to takeover simply by sending a message.
    • by Anonymous Coward on Wednesday February 11, 2009 @12:01PM (#26814673)

      Like sendmail has never had critical vulnerabilities in its address parsing code?

      The irony is that the error is in MS's proprietary TNEF format. This is a binary format so it should be easy to parse.

      Offtopic, but why can't slashdot link to the meat [microsoft.com] rather than some ad-laden rehash?

      • yeah but qmail hasn't :p

      • Sendmail is infinitely more configurable and complex than Exchange Server's SMTP MTA. Don't get me wrong, I'm not defending sendmail's history, but using flaws in something as complex as humans to justify flaws in unrelated bacteria doesn't cut it.

      • From what I understand the more recent sendmail vulnerabilities [securityfocus.com] involved attacking the server. While it wasn't fully divulged the bug noted:

        This requires creating very specific timing conditions using SMTP connection layer commands and delivering specific email payload. Someone with specific network programming skills would be required to create a successful exploit.

        My reading of this is that it took a specific email and an active attack at the same time. The Exchange vulnerability only requires specifica

      • Offtopic, but why can't slashdot link to the meat rather than some ad-laden rehash?

        I think you answered your own question.


      • Like sendmail has never had critical vulnerabilities in its address parsing code?

        I find it extraordinarily funny that Sendmail... probably the most insecure example of a popular open source program, is what you've chosen to compare to Exchange. Years ago there used to be a sendmail vulnerability every week!

        Hell, even sendmail is more secure these days. I still won't use it though, mostly because it's a bear to configure and postfix is far better for anything I've used it for.

    • Re: (Score:2, Informative)

      It is possible... this is usually the symptom of buffer overflow error in the server code. An attacker discovers the hole, takes advantage of the vulnerable buffer to "smash the stack", and dupe the process to execute the shellcode (concise machine code that does whatever an attacker wants) planted in the "specially crafted" mail text.

      There are other possibilities but buffer overflows are among the most common ones. I didn't RTFA and neither do I know whether this is one but yes, taking over the server by m

      • > this is usually the symptom of buffer overflow error in the server code.

        I really don't understand much about MS technologies, but why their Exchange server is not rewritten in C# so at least buffer overflows can be avoided?

    • Thank goodness my Exchange server is behind a firewall *and* a Postfix SMTP proxy running on a Linux box. There's no direct exposure of Exchange to the outside world.

      • Re: (Score:3, Informative)

        by lukas84 ( 912874 )

        Unluckily for you, this vulnerability will still affect you. If you read the security announcement by Microsoft, a possible workaround is to block all TNEF / winmail.dat attachments, which will break all incoming RTF mail. Depending on what your business exactly does, this might not be a viable workaround.

        • Or, you know, you could install the patch, and not worry about the workarounds...
        • It will only break incoming mail that uses TNEF attachments. It's perfectly possible to send rich-text mail without TNEF.

          And since we don't use Outlook as a mail client, I actually filter all incoming messages to extract the actual attachments from those stinking winmail.dat file before the mail is delivered. You could do the same thing at the postfix server so that Exchange never sees TNEF files.
      • by SatanicPuppy ( 611928 ) * <Satanicpuppy@nosPAm.gmail.com> on Wednesday February 11, 2009 @01:04PM (#26815719) Journal

        Wow, you have a firewall that stops email from getting to a mail server! I gotta get me one of those...It would reduce my workload by 95%! Since I don't answer any of my phones, the only way people could contact me with problems would be by ambushing me on the way to the bathroom.

        It would keep the CEO from ever contacting me, that's for sure. God knows he'd never be caught down here with people who do work.

        • No, I have a Postfix server exposed on port 25, while the Exchange server sits unexposed behind the firewall. The Postfix server receives, processes (if necessary, to turf spam, etc) and then passes on mail to the Exchange server. The Exchange server then passes mail off to the Postfix for outgoing transmission.

          • by ozric99 ( 162412 )
            Yes, many other people have that exact same setup, I know I do. The thing is, unless you configure Postfix to drop any application/ms-tnef it's totally irrelevant to this discussion considering Postfix will simply forward the offending e-mail to Exchange. This isn't about spam, and good luck if you're waiting for your AV to get updated with a fix for the as yet unknown mail.

            Besides, what happens when someone combines this with, say, a flash vulnerability and causes a machine inside your network to send
          • by Amouth ( 879122 )

            i do the same thing with sendmail - and guess what? unless you are sure to strip everything of all possiable TNEF data then if one of the "special" e-mails passes your spam filtering it will go right on to the exchange server where it will be proccessed and you will be screwed.

            this isn't someone sending a malformed SMTP message that effects only exchange's SMTP MTA.. this is specialy formatted content inside a perfectly ligit e-mail. no normal or even abnormal spam filter would catch this if it was directe

        • Re: (Score:3, Interesting)

          by DarkOx ( 621550 )

          Well the firewall won't help you with this vulnerability because even after the message is handled though the other mail gateway it can still be a threat. It is however very common to not let exchange speak directly the the outside world. I for one block all smtp at my edge firewall except to and from a cluster of Barracuda Spam filters. They also used to be configured as a smart host in the E2K3 world. In 2k7 i simply don't use the edge transport rule and let the hub transport server treat them as a sen

          • I was more referring to the firewall aspect; struck me as funny. I once went to a property to do a security audit, and found that their firewall literally blocked EVERYTHING. No ports open at all inbound OR outbound. They paid for a broadband connection, but the individual computers were all on dialup, because they thought that's just how teh interwebs worked.

            We run a secure proxy for OWA, sendmail proxy for DMZ'd email handling, a SAV gateway for virus scanning, and upstream of our internal systems we pay

      • If your exchange server will handle this message in the routing chain, you're vulnerable.
  • by Fred_A ( 10934 ) <fred@ f r e dshome.org> on Wednesday February 11, 2009 @11:44AM (#26814319) Homepage

    It's all closed source, so there aren't any real vulnerabilities. Even the certified professionals [slashdot.org] say so. They're certified what more do you need !

    As if you could spread havoc through email [google.com] on a proprietary system. Bah.

  • Oddly enough... (Score:4, Informative)

    by smooth wombat ( 796938 ) on Wednesday February 11, 2009 @11:49AM (#26814409) Journal

    the IE fix ONLY affects IE 7. If you're running IE 6 (or even 5) on any platform, you don't have a patch to install.

    Could it be, *gasp*, that IE 6 is more secure than IE 7? The mind wobbles.*

    *For you yungins, go look up Kelly Bundy and the above phrase.

  • Why in the world would an e-mail delivery system ever consider executing external code? Exchange should simply look at the delivery address. If it is a local address, place the message in the user's mailbox. If an external address, forward to the next hop. What's so difficult with that task?

    CommuniGate Pro has never had this problem. IronPort appliances don't have this problem. Exchange should stick to its sole job as a delivery agent and stop trying to be so smart.

    Can't we live without OLE?

    • by Anonymous Coward on Wednesday February 11, 2009 @12:42PM (#26815361)

      Why in the world would an e-mail delivery system ever consider executing external code?

      Exploits such as the ones mentioned aren't because the system is executing external code intentionally, rather, a carefully crafted message will overflow a buffer and change the values of some CPU registers. If the values change in such a way that a pointer moves execution to a part of the carefully crafted message, that message is now external code that is being run.

      • Exploits such as the ones mentioned aren't because the system is executing external code intentionally, rather, a carefully crafted message will overflow a buffer and change the values of some CPU registers.

        But that overflow would be impossible if Exchange wasn't trying to act on the contents of messages flowing through it. For instance, it's impossible to make Postfix choke on an attachment since it doesn't try to process them (with the minor exception of filtering on the headers of encapsulated emails if you specifically enable that functionality).

    • Exchange needs to be so smart so that it can open up the TNEF document and scan it for content which would route it depending on a user rule, an Antivirus scan need, or a content filter the admin may have.

      And yes, CommunicateGate PRO has had it's share of serious problems just like almost any software;
      http://secunia.com/advisories/search/?search=CommuniGate [secunia.com]

      One of these allows file access as root.

  • I am not surprised by the announcement of these major flaws, many directly related to MS proprietary components/protocols. Microsoft has a history of manipulating open standards into MS proprietary protocols in order to prevent development outside Windows. However, as a result, Windows OS's become less compatible with other OS's and do not reap the benefit of improvements to open source alternatives made in the open source and standard organization communities. Several examples of flawed Windows propriet
  • So.... (Score:5, Funny)

    by Trashman ( 3003 ) on Wednesday February 11, 2009 @01:33PM (#26816233)

    ....What "carefully crafted message" would I need to send to take over an Exchange Server?

    To: ExchangeServer@company.com
    Subject: H3ll0

    I 0wn you Now. Please reply back with passwords.

    Regards,
    Hax0r

    • My buddy figured out how to craft the message. He emailed me the message this morning at work. Hmm, maybe that's why its such a quiet day.

  • We installed it ... (Score:3, Interesting)

    by humph2 ( 1248316 ) on Wednesday February 11, 2009 @01:50PM (#26816541)

    ... and Exchange 2003 stopped delivering messages to mailboxes.

    Rolled it back, and everything worked fine ^H^H^H^H just as it used to.

    I may be missing the point of these "fixes", but surely "security updates" should actually be tested at some stage?

    • by lukas84 ( 912874 ) on Wednesday February 11, 2009 @02:17PM (#26817053) Homepage

      Yes, they should. Namely by you. In your testing environment. Before deploying it to production.

      • I think what the parent is describing isn't going to be solved by a test environment.
      • by citylivin ( 1250770 ) on Wednesday February 11, 2009 @05:37PM (#26820129)

        I had the same with exchange 2007. Calendaring stopped working so I reinstalled rollup 5 and everything went back to normal.

        As for your comment, one day when you move into the "real world" you will realize that you dont always have the resources to test every single patch that comes down the line. Id much rather have a microsoft patch fubar the machine than have a haxxor pwning it because i was busy testing a patch. At least when i have to explain to management why the email was down for 30 minutes, I can blame microsoft instead of saying that we got exploited (which would then become MY fault).

        Not everyone can afford to have redundant everything. Especially machines that are only used for testing, and therefor not in a production environment, where it is easier to find bugs. Sure, if your exchange server services 2000+ users, or generates tens of thousands of dollars a day then maybe you can afford another machine to test on. Most people in the Real World do not have those luxuries.

"The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts." -- Bertrand Russell

Working...