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] [day] [month] [year] [list]
Message-ID: <2b87e78b0511221551x3a66fc52se55ea49e26da7b08@mail.gmail.com>
Date: Tue Nov 22 23:52:03 2005
From: discojonny at gmail.com (Disco Jonny)
Subject: XCP2 v XCP - more than sony at fault?

hi,

I this this has to be one of the most coherent emails on this subject,
and i agree 100% with this post an previous posts in this thread. (i
have had a few beers so in reality it might be more like 98%)

anyway i digress,

My point is/was,

This whole backlash has come about because a home music listener, who
is computer smart (sorry i dont know enough about you to give you more
props) installed a cd that was *bought from a shop*  in 2005 and had
this issue (XCP2)

I think that this rookit shit has been going on since 2002.

What i read from that website(first 4) was that sony have been using
XCP1 since 2002 on prerelease stuff. Whilst 99% of the population will
never own these versions, they will hear them on the radio, before
they get to the shops.
I want to know if the pre release stuff has teh same issue. (because
press and radio stations have been getting these for 3 years!)

whilst your (that is not you spesifcally bkfsec) are rught i think you
missed my point.

The trust thing is paramount in this.  I should not have to educate
these people not to play CD's from Sont, EMI, etc. they should be
safe. end of. no arguments.... not everyone can be security savvy, it
all most of my friends can do to be web savvy...

beer is getting hte better of me now, so i best go

cheers then

S.


On 11/22/05, bkfsec <bkfsec@....lonestar.org> wrote:
> 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
>
>
> _______________________________________________
> 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