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-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 5 Dec 2007 23:57:19 -0500
From: "Dude VanWinkle" <dudevanwinkle@...il.com>
To: Valdis.Kletnieks@...edu
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: need help in managing administrators

On Dec 5, 2007 11:10 PM,  <Valdis.Kletnieks@...edu> wrote:
> On Wed, 05 Dec 2007 22:45:39 EST, Dude VanWinkle said:
> > You are right, thanks for all the careful planning and well thought
> > out infrastructure. I mean, who could have thought that the ability to
> > reach into the homes of every tom dick and harry as well as every
> > company on the planet would be used for swindling cash?
>
> I'd like to see you find *any* evidence that the guys who did the original
> design work had *any* serious reason to expect that 15 years later, somebody
> would change all the AUPs and let Joe Sixpack on the net.

Isn't a majority of abuse from internal users? You should design a
system to be independent of the users, maybe I will just file that
under "lessons learned"

> For that matter, you're welcome to come up with security protocols that would
> have been acceptable on the hardware of the time, or in the computer culture
> of the time.

Good argument. I now just throw massive equations at the processor and
expect them to be done ASAP. I guess my digital watch has more
processing power than MULTIVAC (the Internet USED to be tubes, as
MULTIVAC will attest to).

> Remember - we're talking about a time when you really *could*
> get all the TCP/IP users on the planet around one table in a conference room,
> and picking up the phone, dialing a number you knew already, and saying
> "Hey Bernie, will you smack your user upside the head?" and know that Bernie
> would do it, because Bernie was expecting you to do it if he called you.

Thats what i am saying, if it was that easy... damn, you could (and
probably did to some extent) have affected the entire thing with one
phone call. Do you realize what it takes now-a-days to have that same
effect? I would have to subpoena all the governments, educational
institutes, and businesses on the planet; then wait 50 years for the
measures to be implemented

> Some dude at MIT called Stallman was even running machines that didn't have
> passwords, and everybody logged in as "system admin" - and the world didn't
> end.

I recommend pb/pmrun ;-)

> Now tell me how you would have imposed the sort of security needed today on
> that environment. ;)

try this "hey boss, you will cause regulation, expose national secrets
to commies, cause billions of lost dollars, and develop an
infrastructure that will destroy the worlds economy if taken down that
subsists on 13 servers, enable women to vote, and Africans will be
treated as equals"

;-) Just kidding about the women and african comment, but man, the
past asked for that one... :-)

> The tech was different, the culture was different.  The amazing thing is
> that it still works as well as it does in today's tech and culture.

Agreed, just amazing.

> > So you knew this 30 years ago, and didn't change squat, and we are
> > still dealing with it now.
>
> A lot of us understood all this 30 years ago, but some vendors made conscious
> choices regarding the usual security/bling/ease-use trade-offs that in
> retrospect, were not in the community's best interests.

Profit, sweet profit...


> >                            How fuscking hard is it to design a system
> > with separate processors|memory for command|data channels?
>
> It's not hard - it's called a Harvard architecture (as opposed to the
> Von Neumann architecture we know and love, where one memory has both
> program and data in it).  The problem is that *loading* program code
> into such an architecture requires some finesse, because almost by
> definition, the program loader is treating some other program's code as
> data, and thus shouldn't be allowed to do a "data store" operation into
> "program storage" memory locations (Go ahead - *try* to write even a simple
> program loader that doesn't treat the loaded program's bytes as data - it
> *is* fsck'ing hard.. ;)

Well say:

proc 1=commands and can be but anywhere on proc1/memory1
proc2=data:can be put anywhere that will display on video cards, or a
process that is used to enter data (only  No Exec, Stack Cookies, Heap
Cookies, SafeSEH.. just data)

Easy in hindsight :-) JK Joke, AFAIK we wouldn't need these things
with separate memory spaces and processors (EIP=1, not 2)

> Or you could go the EEPROM/CDROM route like most game consoles did.  That's
> easier on the practicality side, but still isn't as flexible as a
> general-purpose PC.


Dumb Terminals are the future. End users and corps are tired of SW
upgrade, losing info, backing up, viri, etc

-JP

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ