Announcement

Collapse
No announcement yet.

Linux Kernel Exploit Affecting Linux 3.3 To Linux 3.8

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Originally posted by Detructor View Post
    they should port the whole kernel to C#/.NET. There you got a nice garbage collector and don't have to worry about strange things like pointers and a buffer/memoryoverflow get's a nice exception.

    ok, but seriously...someone should implement a background garbage collector and some meta-error handling in C and C++. That'd get rid of those 'security holes' instantely.
    Actually doing that is a rather interesting way to do a microkernel and there's this project http://www.mosa-project.org/ and Microsoft Midori doing a managed microkernel in C#. I'll definitely be interested to see if either of those actually goes anywhere.

    Comment


    • #17
      Originally posted by dee. View Post
      Mapplesoft, mipple, just different sides of the same shitty coin.
      Lol... really funny.

      C isn't a bad lang, it's just trap central for bad programming.

      Comment


      • #18
        1: If you're on Debian Wheezy or Ubuntu 12.04, you're still affected.
        The commit introducing this is actually from just before 3.2.
        2: The patch was committed by a Red Hat employee, but was written by a Parallels employee.
        Code:
        sock_diag: Initial skeleton
        author	Pavel Emelyanov <xemul@parallels.com>	
        	Tue, 6 Dec 2011 07:58:03 +0000 (07:58 +0000)
        committer	David S. Miller <davem@davemloft.net>	
        	Tue, 6 Dec 2011 18:58:01 +0000 (13:58 -0500)
        commit	d366477a52f1df29fa066ffb18e4e6101ee2ad04
        tree	267a65f626108423f73ef6dc0040b3b3171f7b45	tree | snapshot
        parent	f13c95f0e255e6d21762259875295cc212e6bc32	commit | diff
        Now I'm off to build a new kernel for my Squeeze system.

        Comment


        • #19
          Originally posted by JS987 View Post
          David S. Miller is Red Hat employee
          http://en.wikipedia.org/wiki/David_S._Miller
          A CIA agent for sure. Linus should really investigate kernel contributors before letting them submit code, because who knows how many CIA agents and/or M$ employees are willing to introduce backdoors in Linux ?

          Comment


          • #20
            http://lwn.net/Articles/539885/

            Apparently, with SELinux enabled on Fedora 18, the exploit code failed to run.

            Comment


            • #21
              Originally posted by Ibidem View Post
              1: If you're on Debian Wheezy or Ubuntu 12.04, you're still affected.
              The commit introducing this is actually from just before 3.2.
              2: The patch was committed by a Red Hat employee, but was written by a Parallels employee.
              Code:
              sock_diag: Initial skeleton
              author	Pavel Emelyanov <xemul@parallels.com>	
              	Tue, 6 Dec 2011 07:58:03 +0000 (07:58 +0000)
              committer	David S. Miller <davem@davemloft.net>	
              	Tue, 6 Dec 2011 18:58:01 +0000 (13:58 -0500)
              commit	d366477a52f1df29fa066ffb18e4e6101ee2ad04
              tree	267a65f626108423f73ef6dc0040b3b3171f7b45	tree | snapshot
              parent	f13c95f0e255e6d21762259875295cc212e6bc32	commit | diff
              Now I'm off to build a new kernel for my Squeeze system*.
              1 is incorrect: it dates to a month before 3.2, but was committed to net-next rather than Torvald's tree.


              *I don't run straight Squeeze: I use an upstream LTS kernel, currently 3.4, plus several backports and built-from-git packages.

              Comment


              • #22
                Originally posted by wargames View Post
                A CIA agent for sure. Linus should really investigate kernel contributors before letting them submit code, because who knows how many CIA agents and/or M$ employees are willing to introduce backdoors in Linux ?
                Why don't you go then and carefully review each commit this CIA agent has submitted, there's bound to be more exploits if your hypothesis is true... really, you'd be doing us all a huge favour, we'd probably build you a statue or something.

                Comment


                • #23
                  heh, just upgraded 3.2.12 to 3.7.9 ... oh well ... will have to look at gentoo updates/news

                  Comment


                  • #24
                    Originally posted by Cthulhux View Post
                    Well, how do they say? "Open source is more secure because more people can see what's going on". Hahaha. Great.
                    I wonder how many security flaws were identified in Windows(privately or openly) in the last year compared to Linux/BSD.
                    Somehow, I think this is in the opensource's favor.

                    Comment


                    • #25
                      Originally posted by haplo602 View Post
                      heh, just upgraded 3.2.12 to 3.7.9 ... oh well ... will have to look at gentoo updates/news
                      Jeez was this a server or something, that's a good leap there!

                      Comment


                      • #26
                        Originally posted by Cthulhux View Post
                        Well, how do they say? "Open source is more secure because more people can see what's going on". Hahaha. Great.
                        And it is. It's far more secure than proprietary crap.

                        Comment


                        • #27
                          Originally posted by Luke_Wolf View Post
                          Actually doing that is a rather interesting way to do a microkernel and there's this project http://www.mosa-project.org/ and Microsoft Midori doing a managed microkernel in C#. I'll definitely be interested to see if either of those actually goes anywhere.
                          So, they use shit to make even worse and slower shit than winblows is?

                          Comment


                          • #28
                            Originally posted by johnc View Post
                            I was just going to say that C has got to be the worst language imaginable.
                            It's far better than c# and probably the best for kernel programing.

                            Comment


                            • #29
                              This news is really alarming since according to my understanding this spcific bug can only happen as a result of really sloppy coding practices or deliberate sabotage!?

                              Why has not Linux foundation put up some prize money for reported 0-day vulnerabilities? Would it be such a burden for such an organization to promise 10k$ for every submitted 0-day root exploit or something similar? 10k would be huge money for a security researcher but pocket change for Linux foundation. This would encourage the 0-day to be reported rather than sold for profit.

                              Comment


                              • #30
                                Originally posted by Detructor View Post
                                they should port the whole kernel to C#/.NET. There you got a nice garbage collector and don't have to worry about strange things like pointers and a buffer/memoryoverflow get's a nice exception.

                                ok, but seriously...someone should implement a background garbage collector and some meta-error handling in C and C++. That'd get rid of those 'security holes' instantely.
                                Sure, using some type of managed array in the case of this function would have prevented this *specific* security hole, but the performance hit of using only managed array within the kernel would have made it far from being acceptable and this is only one *specific* attack vector. (Let alone using fully managed programming language inside the kernel *).

                                Any one that ever written large chunks of kernel code knows that you do your best to verify user-supplied parameters, but being human, you will fuck up from time to time.

                                - Gilboa
                                * ... In which case most attack vectors will simply target the managed language VM.
                                DEV: Intel S2600C0, 2xE52658V2, 32GB, 4x2TB + 2x3TB, GTX780, F21/x86_64, Dell U2711.
                                SRV: Intel S5520SC, 2xX5680, 36GB, 4x2TB, GTX550, F21/x86_64, Dell U2412..
                                BACK: Tyan Tempest i5400XT, 2xE5335, 8GB, 3x1.5TB, 9800GTX, F21/x86-64.
                                LAP: ASUS N56VJ, i7-3630QM, 16GB, 1TB, 635M, F21/x86_64.

                                Comment

                                Working...
                                X