lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
From: John.Airey at rnib.org.uk (John.Airey@...b.org.uk)
Subject: DCOM RPC exploit  (dcom.c)

> -----Original Message-----
> From: Nick FitzGerald [mailto:nick@...us-l.demon.co.uk]
> Sent: 29 July 2003 04:12
> To: full-disclosure@...ts.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@...b.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 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ