Slashdot Mirror


Linux X.org Critical Security Flaw Silently Patched

eldavojohn writes "On June 17th, the X.org team was notified by Invisible Things Lab of a critical security flaw (PDF) that affected both x86_32 and x86_64 platforms. The flaw deals with escalated privileges of a user process that has access to the X server. The founder of ITL said of the flaw, 'The attack allows a (unpriviliged) user process that has access to the X server (so, any GUI application) to unconditionally escalate to root (but again, it doesn't take advantage of any bug in the X server!). In other words: any GUI application (think e.g. sandboxed PDF viewer), if compromised (e.g. via malicious PDF document) can bypass all the Linux fancy security mechanisms, and escalate to root, and compromise the whole system.' This has apparently been a security flaw since kernel 2.6 was released. From the article, 'On 13 August, Linus Torvalds committed an initial fix, but several patches were added afterward for various reasons. The problem has been addressed in versions 2.6.27.52, 2.6.32.19, 2.6.34.4 and 2.6.35.2 of the kernel.'"

2 of 259 comments (clear)

  1. Re:What I suggest to people by DarkKnightRadick · · Score: 1, Offtopic

    lol

    Though I wonder how I'm off-topic, considering this is about a Linux vulnerability.

    Oh wait, this is /., nvm

    --
    "There is a way that seems right to a man, but its end is the way of death." Proverbs 16:25 (NKJV)
  2. Re:What I suggest to people by DarkKnightRadick · · Score: 0, Offtopic

    Well, I didn't want to say it was pretty self-explanatory, but in reality it is!

    http://en.wikipedia.org/wiki/Inter-process_communication

    In computing, Inter-process communication (IPC) is a set of techniques for the exchange of data among multiple threads in one or more processes. Processes may be running on one or more computers connected by a network. IPC techniques are divided into methods for message passing, synchronization, shared memory, and remote procedure calls (RPC). The method of IPC used may vary based on the bandwidth and latency of communication between the threads, and the type of data being communicated.

    http://en.wikipedia.org/wiki/Control_flow is the closest I could get to control primitives. Am I far off?

    You mention that control primitives and IPC are pretty important and imply that Mach handled them differently. I'll give you that.

    Upon further reading on XNU, XNU seems to contradict the Mach (kernel) entry entirely:

    The Berkeley Software Distribution (BSD) portion of the kernel provides the POSIX API (BSD system calls), the Unix process model atop Mach tasks, basic security policies, user and group ids, permissions, the network stack, the virtual file system code (including a filesystem independent journalling layer), several local file systems such as HFS/HFS+, the Network File System (NFS) client and server, cryptographic framework, UNIX System V inter-process communication (IPC), Audit subsystem, mandatory access control, and some of the locking primitives. The BSD code present in XNU came from the FreeBSD kernel. Although much of it has been significantly modified, code sharing still occurs between Apple and the FreeBSD Project.[citation needed][dubious – discuss]

    You'll note I bolded two sections. Seems more was taken from FreeBSD and not a lot of Mach's original stuff.

    But "Ah-ha!" you'll say:

    Mach provides kernel threads, processes, pre-emptive multitasking, message-passing (used in inter-process communication), protected memory, virtual memory management, soft real-time support, kernel debugging support, and console I/O.

    Really not supporting your argument.

    Seems like the Mach and XNU articles need to be updated so they don't contradict each other.

    --
    "There is a way that seems right to a man, but its end is the way of death." Proverbs 16:25 (NKJV)