On Sun, Aug 7, 2011 at 20:15, Duncan <1i5t5.duncan@xxxxxxx> wrote:
>> If you are referring to XSS, then I think that would only apply if each
>> process were to each have it's own cookie store, which I do not believe
>> is the case here. Having separate profiles would help in that case.
>
> That's probably a more practical worry, but what I had in mind was more
> the stick data (say disguised as an image, thus binary data) somewhere and
> exploit a vuln to run it as native code, type thing. Since all memory in
> a single process is accessible, in theory, one can then read all the data
> in all other browser sessions in the same process, without resorting to
> opening files or anything.
>
That would have to be a Konqueror-specific attack. The nice thing
about using a web browser with <1% market share is that nobody will
write a browser-specific attack unless they are attacking a specific
target that they assume uses that browser.
> Of course, the way Linux machines are commonly setup, with all user data
> readable by whatever apps a user runs as long as it's not run setuid (and
> that creates other problems for apps that would typically write config and
> state to a user dir), once one is running native code, it's not difficult
> to grab whatever info from the disk, etc, except that for automated
> attacks one must anticipate the layout, etc, which can be harder to do
> (especially cross-platform) than simply reading all the data already
> available in the same process.
>
> Meanwhile, still talking about security, but no longer about konqueror or
> browsers specifically, did you know that everything a user types into an X
> session, including root passwords, etc, AND everything entered in that
> root session as long as it's running in the same X session, can be sniffed
> by ANY other process in that X session? Even if said other process is
> running as SETUID nobody or the like? (Actually, there is apparently one
> way to capture input exclusively, but it's very seldom used because it's
> visually disruptive and effectively blocks everything else until its done.
> Think the MS Windows BSOD, or Red AV warning screens, or whatever, that's
> the type of exclusive mode and the disruption it causes that we're talking
> -- IOW, they faced some of the same physical hardware and design issues.)
>
I did not know that. I'd like to know what attacks exploit this, and
if there are any relevant bugs filed.
> That's the way X was designed. Think about that the next time you're
> entering your root password or GPG passphrase into an X-based dialog box!
>
> That's one of the reasons I'm following qubes, which uses walled off xen
> sessions, with some interest. (SELinux and nested X can do some of the
> same stuff as well, but leaves a rather larger attack surface.)
>
> For further reading -- I did the suggested experiment (second link) and
> suggest that you try it too. If the results don't change the way you work
> in X at least a bit, either you already know all about it, you keep
> absolutely all private stuff either off the system entirely or in another
> account you don't access from your "play" account, or you're simply too
> drugged out to care! The third link explains the Qubes-OS VM partitioning
> concepts and has a couple diagrams for per-VM network connectivity and
> data flow between the VMs.
>
> http://blogs.pcmag.com/securitywatch/2011/04/why_your_linux_desktop_is_inse.php
>
> http://theinvisiblethings.blogspot.com/2011/04/linux-security-circus-on-gui-isolation.html
>
> http://theinvisiblethings.blogspot.com/2011/03/partitioning-my-digital-life-into.html
>
Thanks, Duncan. That is good to know! I'll keep this in mind when the
Ubuntards start bashing Microsoft security around, too!
Have a great week.
--
Dotan Cohen
http://gibberish.co.il
http://what-is-what.com
___________________________________________________
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
