I just noticed: no more crashes! Thanks, KDE team!
dotancohen at gmail.com
Sun Aug 7 22:05:36 BST 2011
On Sun, Aug 7, 2011 at 20:15, Duncan <1i5t5.duncan at cox.net> 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.
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.
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
More info: http://www.kde.org/faq.html.
More information about the kde