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]
Message-ID: <43837185.3060806@sdf.lonestar.org>
Date: Tue Nov 22 19:30:12 2005
From: bkfsec at sdf.lonestar.org (bkfsec)
Subject: XCP2 v XCP - more than sony at fault?

Larry Seltzer wrote:

>>>Running a restricted user account by default would also help (no admin
>>>      
>>>
>privileges given to the application located on the CD).
>  
>
>>>I recommend everyone to get into this habit when using Windows desktops.
>>>      
>>>
>In cases in which you need admin privileges to install an application you
>can just use the command "run as" by right-clicking on the executable to
>install. 
>
>Ditto to all of this. It's not just good practice, it specifically stops the
>XCP software which reports that it (actually, it says that the music player)
>requires administrator privileges to install. I'm sure most people would
>just login as admin and install, but at least at that point you're
>explicitly pointing the gun at your own head and pulling the trigger.
>
>  
>
I agree with the general points about using non-privileged users and as 
well for disabling auto-run.  However, I think that you made the right 
point by saying that "most people would just login as admin and 
install", but I think that this thinking may represent a problem for the 
information technology industry and security.

The problem, of course, is normal users.  Yes, security professionals 
have gotten hit with this.  But most security professionals are pretty 
savvy when it comes to operating their PCs.  For the most part, I'm not 
too concerned with what we do.  And we're the only ones who will 
actually, unfortunately, be helped by these suggestions.

Most normal users will still double-click on the CD to execute the content.

Most normal users will still happily run as admin in order to execute 
the installer.

Trust is the issue in this situation.  People trusted Sony, and Sony 
violated that trust.  Unfortunately, there are no easy solutions.  As 
long as people are allowed to execute random code on their own 
computers, trust will continue to trip people up.  I'm not sure that 
there is an easy answer to this.  But those of us who are security savvy 
should begin thinking about what our answers will do for the average 
user.  The advice given here is a step in the right direction, but I 
don't personally believe that it will end the flood of malware and the 
like out there.  I think that the people cracking systems and installing 
crap like XCP are going to continue doing it, knowing full well that 
trust is their ally.

So what is the solution?  I don't know really... it's a tough nut to 
crack.  Education works well, but what do we say in this case?  Say 
"Trust no one because large corporations will screw you as badly as 
everyone else?"

Thanks Sony - you really made our jobs easier here.  /sarcasm

And what about the vaunted end goal of hardware-based DRM?  Restriction 
of what can be installed on a person's system.  I'm not comfortable with 
that either... first of all because we all know that it won't take 
people long to find a way around it and those people illegally 
distributing malware could care less about violating the DMCA.  Second 
of all because something like that won't stop companies from installing 
crap like XCP.  And third of all because it reduces the ability for 
people to control their own environments, making crap like XCP harder 
for people to remove (which is a wholesale loss for the consumer).

So what's the permanent fix here?  I don't know... I think I, as well as 
everyone else, am open to new ideas.   I think that we, as an industry, 
need to very seriously think about what the safest method of installing 
and auditing new code is.  The best thing I can think of at the moment 
is an OS-defined new-code sandbox that can't access anything else until 
approved... but that's only a start, and is still somewhat subjected to 
the trust factor.

                -bkfsec


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ