Re: FW: Possible flaw in XFree?

From: Nick Lange (nicklangeat_private)
Date: Sat Jun 29 2002 - 16:38:03 PDT

  • Next message: strangeat_private: "Re: OpenSSh 3.4p1 PrivilegeSerparation experiment"

    Which once again leads us back to a point that perhaps more people would
    agree with,
    the option should *not* be enabled by default precisely for the
    annoyance/information loss factor. First off, any user can kill off any
    other user's session (provided they have access to the hardware running the
    session) which can lead to potential data loss for any running applications.
    This could be done out of malice, etc. Like I said, any machine set up with
    stable code should *NOT* crash and should not need to have this feature
    enabled by default. If it needs to be enabled, then let the administrator
    enable it. This also protects for the above scenario against incompetent
    admins, new admins, new users etc who might not realize this is a feature...
    And for those who need it, they can enable it.
    As I said, this is a more agreeable solution, no?
    nick
    ----- Original Message -----
    From: <strangeat_private>
    To: <vuln-devat_private>
    Sent: Saturday, June 29, 2002 10:10 AM
    Subject: Re: FW: Possible flaw in XFree?
    
    
    >
    > My reply I sent personally:
    >
    > On Sat, Jun 29, 2002 at 09:16:26AM -0400, Andy Wood wrote:
    > > First, I do not believe there is s problem with switching
    > > consoles as each sonsole is the users responsibility, but if they secure
    > > their consoles and xwin and you can end around it with a default config
    > > there is a problem.
    >
    > The problem here is that he thought that by securing the X console he was
    > securing the text console also.
    >
    > > Microsoft got tore up about being able to
    > > ctrl-alt-del and end tasking the screen saver to avoid the password
    > > issue.
    >
    > You can't avoid the screen saver password by ctrl+alt+bs. You'll kill the
    > session, not just the screen saver. The ctrl+alt+bs is comparable to the
    > new Windows XP, when you can lock your session but other users can still
    > create their own sessions.
    >
    > > It is a serious security hole, and, because of that should not
    > > be the default configuration, even if it is fixable.
    >
    > It's not a security hole, you can't gain any privileges by ctrl+alt+bs a
    > user's X session. It is an annoyance, but I'll rather have that than have
    > X block my screen and be unable to kill it.
    >
    > I wouldn't mind packagers to ship it without that option as default (I
    > would just activate it on my own), but I don't think that's a security
    > issue.
    >
    > > Someone only has
    > > to miss it on one system once and a security breach can occur.  Using a
    > > graphical (give me a break) manager is surely not an acceptable
    > > solution.
    >
    > What's wrong with using a graphical manager? I'll rather enter just my
    > name & password than then execute 'exec startx' or 'startx & exit'.
    >
    > > I hate MS and it makes me happy to hear them get slapped around
    > > when a ridiculous default config causes a major security hole. So, the
    > > same standard needs to be applied here...especially when you know who is
    > > watching and looking for anything to discredit a real OS to better
    > > leverage their sub-standard trash code.
    >
    > Again, I don't think this is a security hole, much less a "major security
    > hole". I can't gain anything by ctrl+alt+bs some user's X session, I'll
    > just annoy him. And sometimes I just need to "zap" his sesion.
    >
    > Regards,
    > Luciano Rocha
    



    This archive was generated by hypermail 2b30 : Sat Jun 29 2002 - 15:06:04 PDT