[Declude.JunkMail] Vulnerability in RPC on Windows DNS Server Could Allow Remote Code Execution

2007-04-13 Thread Darrell \([EMAIL PROTECTED])
FYI - This looks pretty serious and will probably affect most of us. This alert is to notify you that Microsoft has released Security Advisory 935964 - Vulnerability in RPC on Windows DNS Server Could Allow Remote Code Execution - on 12 April 2007. Summary: Microsoft is investigating new

RE: [Declude.JunkMail] Vulnerability in RPC on Windows DNS Server Could Allow Remote Code Execution

2007-04-13 Thread Andy Schmidt
Hi Darrell: It does NOT effect the DNS port - ONLY RPC connections. So, if someone has infiltrated your local network ALREADY, then they can issue remote procedure calls (which is what the DNSadmin uses to manage your DNS server from your workstation) to also gain access to your DNS server

RE: [Declude.JunkMail] Vulnerability in RPC on Windows DNS Server Could Allow Remote Code Execution

2007-04-13 Thread John T \(lists\)
But from what I read last night, it is only serious if some one is running a MS DNS server that is not behind a firewall or otherwise has the range of ports in question open from the Internet. John T -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of

Re: [Declude.JunkMail] Vulnerability in RPC on Windows DNS Server Could Allow Remote Code Execution

2007-04-13 Thread Darrell \([EMAIL PROTECTED])
It does NOT effect the DNS port - ONLY RPC connections. So, if someone has Correct. Assuming that everyone is firewalling their servers so that only necessary ports are open on the outside, this is not a high priority item. However, for ISP's that use MS DNS servers and do remote

Re: [Declude.JunkMail] Vulnerability in RPC on Windows DNS Server Could Allow Remote Code Execution

2007-04-13 Thread Matt
However, for ISP's that use MS DNS servers and do remote management from the inside - their customers could potentially exploit them. I have worked with folks who run services other than mail on their DNS servers. One example is FTP. With passive ftp high ports 1024+ need to be open both

RE: [Declude.JunkMail] Vulnerability in RPC on Windows DNS Server Could Allow Remote Code Execution

2007-04-13 Thread Mark Reimer
You could do Microsoft's registry workaround if you are not using the remote management. Mark Reimer IT System Admin American CareSource 972-308-6887 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Sent: Friday, April 13, 2007 10:58 AM To: [EMAIL

RE: [Declude.JunkMail] Vulnerability in RPC on Windows DNS Server Could Allow Remote Code Execution

2007-04-13 Thread Mark Reimer
While we are on the topic of vulnerabilities I just saw 2 new vulnerabilities found in clamav. Mark Reimer IT System Admin American CareSource 972-308-6887 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Reimer Sent: Friday, April 13, 2007 12:26

Re: [Declude.JunkMail] Vulnerability in RPC on Windows DNS Server Could Allow Remote Code Execution

2007-04-13 Thread Darrell \([EMAIL PROTECTED])
Mark, You have a link for those? Darrell Check out http://www.invariantsystems.com for utilities for Declude And Imail. IMail/Declude Overflow Queue Monitoring, SURBL/URI integration, MRTG Integration, and Log Parsers.

RE: [Declude.JunkMail] Vulnerability in RPC on Windows DNS Server Could Allow Remote Code Execution

2007-04-13 Thread IS - Systems Eng. \(Karl Drugge\)
This shouldn't be an issue for most of us. My DMZ boxes are already as hardened as I can get them, with the firewall ( ingress and egress ), patches, and IP filtering. I would think that most ISP's and corporate networks would be using the same techniques. We gave up relying on M$ and other vendor

Re[2]: [Declude.JunkMail] Vulnerability in RPC on Windows DNS Server Could Allow Remote Code Execution

2007-04-13 Thread Sanford Whiteman
It is also odd and possibly grossly incompetent of Microsoft to choose to use ports 1024+ for such purposes, but I'm thinking that they have some weakly justifiable reason to do this as a feature. RPC endpoints always choose dynamic ports in the customary ephemeral range, not the

Re: [Declude.JunkMail] Vulnerability in RPC on Windows DNS Server Could Allow Remote Code Execution

2007-04-13 Thread Matt
Sounds then like it should be more specific. It would seem to make sense not to expose services such as DNS, which run as SYSTEM and has full rights, to RPC traffic on variably assigned ports higher than 1024. Maybe that makes more sense. We're awfully lucky that stateful firewalls evolved

RE: [Declude.JunkMail] Vulnerability in RPC on Windows DNS Server Could Allow Remote Code Execution

2007-04-13 Thread Mark Reimer
http://secunia.com/advisories/24891/ Mark Reimer IT System Admin American CareSource 972-308-6887 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darrell ([EMAIL PROTECTED]) Sent: Friday, April 13, 2007 12:51 PM To: [EMAIL PROTECTED] Subject: Re:

RE: [Declude.JunkMail] Vulnerability in RPC on Windows DNS Server Could Allow Remote Code Execution

2007-04-13 Thread Colbeck, Andrew
The Administrators who should be applying the workaround are precisely the same Administrators that have accidentally allowed inbound connections on arbitrary ephemeral ports, i.e. if they clumsily opened connections as per Darryl's suggestion of how/why this lack of firewalling might happen. If

Re: [Declude.JunkMail] Vulnerability in RPC on Windows DNS Server Could Allow Remote Code Execution

2007-04-13 Thread Matt
Just curious...wouldn't it make sense to apply the patch unless one's DNS server is firewalled both internally and externally? We have seen botnet owners launch high volume trojan campaigns at the drop of a hat, and if it is in fact the botnet owners that are going to exploit this, it would

RE: [Declude.JunkMail] Vulnerability in RPC on Windows DNS Server Could Allow Remote Code Execution

2007-04-13 Thread Colbeck, Andrew
Just curious...wouldn't it make sense to apply the patch unless one's DNS server is firewalled both internally and externally? Definitely! I'd go as far as to say that it is reasonable to apply the same security concepts to your internal network as you do for your external network and DMZ.