Full Disclosure mailing list archives
RE: DCOM RPC exploit (dcom.c)
From: John.Airey () rnib org uk
Date: Tue, 29 Jul 2003 11:55:55 +0100
-----Original Message----- From: Nick FitzGerald [mailto:nick () virus-l demon co uk] Sent: 29 July 2003 04:12 To: full-disclosure () lists netsys com Subject: RE: [Full-disclosure] DCOM RPC exploit (dcom.c)
[snip]
Of course, convincing a bean-counter of the value of taking a longer- term view of such issues is really difficult and almost exclusively you will only ever find such principles applied in practice at _extremely_ sensitive installations and at large corporations that have been "hit" very severely because they got it wrong the first time. After seeing the lack of value of scrimping on critical infrastructure there is a tendency for upper management backing for "doing it right" the second time around. I guess that this is almost exclusively how it is means the "it won't happen to us" attitude is alive and well in the halls of corporate governance...
Why do I get the distinct impression that only myself and Paul Schmel actually understand what the realities of life are these days? There is really very little control over "users", whether they are in a "edu" or not. Imagine a company where a user is told by the IT department that such and such a computer can't be used. He then goes and buys it on his own credit card and claims it back on expenses (this happens more than you realise). Said IT department now has to support the machine that he was told he couldn't have, probably because someone higher up in the organisation says that it has to. This computer will probably consume a disproportionate amount of support time. The irony is that the purchaser will probably then tell you it was a bargain (yeah, right!). The bottom line is that these days, the IT departments do not have enough power to enforce any radical suggestions. I'd be surprised if any organisation exists (outside of the military) that insists on knowing the MAC addresses of machines before they get connected to the network. (In our case we monitor MAC addresses instead as we can then spot network problems). I remember the days of dumb-terminals and users who had to ask permission to print. At that time we could control what happened on the network. With the advent of PCs and desktop printers, that's all changed. In a way, we are the victims of our own success. Network connectivity is seen as a right, not a privilege. "Doing it right" usually means getting the IT department to fix a problem caused by someone else's mistakes. The truth is that all sysadmins are all involved in damage limitation, which is why we subscribe to this list. We do our utmost to prevent damage, but recent history shows us just one user clicking on a dodgy email attachment can bring down major networks. In other cases not knowing what a firewall should and shouldn't do has caused other outages (even affecting Microsoft). After all, if what has been suggested is true and has been implemented, why bother to subscribe to this list? - John Airey, BSc (Jt Hons), CNA, RHCE Internet systems support officer, ITCSD, Royal National Institute of the Blind, Bakewell Road, Peterborough PE2 6XU, Tel.: +44 (0) 1733 375299 Fax: +44 (0) 1733 370848 John.Airey () rnib org uk After over 144 years, there's still no fossil evidence of Evolution. - NOTICE: The information contained in this email and any attachments is confidential and may be legally privileged. If you are not the intended recipient you are hereby notified that you must not use, disclose, distribute, copy, print or rely on this email's content. If you are not the intended recipient, please notify the sender immediately and then delete the email and any attachments from your system. RNIB has made strenuous efforts to ensure that emails and any attachments generated by its staff are free from viruses. However, it cannot accept any responsibility for any viruses which are transmitted. We therefore recommend you scan all attachments. Please note that the statements and views expressed in this email and any attachments are those of the author and do not necessarily represent those of RNIB. RNIB Registered Charity Number: 226227 Website: http://www.rnib.org.uk _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Current thread:
- RE: DCOM RPC exploit (dcom.c), (continued)
- RE: DCOM RPC exploit (dcom.c) Ron DuFresne (Jul 28)
- RE: DCOM RPC exploit (dcom.c) Robert Wesley McGrew (Jul 28)
- RE: DCOM RPC exploit (dcom.c) gml (Jul 28)
- Re: DCOM RPC exploit (dcom.c) Valdis . Kletnieks (Jul 28)
- RE: DCOM RPC exploit (dcom.c) Marc Maiffret (Jul 28)
- RE: DCOM RPC exploit (dcom.c) Schmehl, Paul L (Jul 28)
- RE: DCOM RPC exploit (dcom.c) Ron DuFresne (Jul 28)
- RE: DCOM RPC exploit (dcom.c) Admin GSecur (Jul 28)
- RE: DCOM RPC exploit (dcom.c) Nick FitzGerald (Jul 28)
- RE: DCOM RPC exploit (dcom.c) Thiago Campos (Jul 28)
- RE: DCOM RPC exploit (dcom.c) John . Airey (Jul 29)
- RE: DCOM RPC exploit (dcom.c) Nick FitzGerald (Jul 29)
- RE: DCOM RPC exploit (dcom.c) Schmehl, Paul L (Jul 29)
- Re: DCOM RPC exploit (dcom.c) Robert Banniza (Jul 29)
- Re: DCOM RPC exploit (dcom.c) Preston Newton (Jul 30)
- RE: DCOM RPC exploit (dcom.c) Ron DuFresne (Jul 29)
- Re: DCOM RPC exploit (dcom.c) Robert Banniza (Jul 29)
- RE: DCOM RPC exploit (dcom.c) Schmehl, Paul L (Jul 29)
- Re: DCOM RPC exploit (dcom.c) Kain (Jul 29)
- RE: DCOM RPC exploit (dcom.c) Myers, Marvin (Jul 29)
- RE: DCOM RPC exploit (dcom.c) Schmehl, Paul L (Jul 29)
- SV: DCOM RPC exploit (dcom.c) Peter Kruse (Jul 29)
(Thread continues...)