Announcement

Collapse
No announcement yet.

NVIDIA 295.40 Closes High-Risk Security Flaw

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

  • NVIDIA 295.40 Closes High-Risk Security Flaw

    Phoronix: NVIDIA 295.40 Closes High-Risk Security Flaw

    NVIDIA's Linux team this morning announced the immediate release of the 295.40 Linux driver. There aren't many changes for this release compared to the recent 295.33 driver release, but it does address a high-risk security vulnerability...

    http://www.phoronix.com/vr.php?view=MTA4NTk

  • #2
    We all love blobs
    ## VGA ##
    AMD: X1950XTX, HD3870, HD5870
    Intel: GMA45, HD3000 (Core i5 2500K)

    Comment


    • #3
      Originally posted by darkbasic View Post
      We all love blobs
      Yes, we're still using a never-updated, initially released Debian 5 in our servers, since its packages are open source and therefore don't have security problems and thus don't need security updates.

      Dude, seriously :-P

      Comment


      • #4
        How long?

        I wonder how long this vulnerability have been known.
        It's just recently been officially announced as discovered, but may have been privately known for years.

        I want open source!

        Comment


        • #5
          Originally posted by uid313 View Post
          I wonder how long this vulnerability have been known.
          It's just recently been officially announced as discovered, but may have been privately known for years.

          I want open source!
          Like the root exploits in the Linux kernel that were there for years? Or the Debian SSL disaster? Give me a break.

          Comment


          • #6
            http://www.reddit.com/r/linux/commen...nvidia/c4aynv6

            Seems to be an old vulnerability, fixed years ago by open source drivers

            Comment


            • #7
              Look at all the goodies the Windows side is getting in the next driver. :|

              Comment


              • #8
                Originally posted by RealNC View Post
                Like the root exploits in the Linux kernel that were there for years? Or the Debian SSL disaster? Give me a break.
                The case is if those exploits were known. If they weren't then what's your point? The only thing that really matters is a time needed for fixing an exploit and Linux is probably the fastest in this. However, according to Phoronix article it seems nVidia does a good job as well.

                Comment


                • #9
                  Originally posted by RealNC View Post
                  Yes, we're still using a never-updated, initially released Debian 5 in our servers, since its packages are open source and therefore don't have security problems and thus don't need security updates.
                  Classy. Actually, no distribution makes fire-and-forget security (dist-upgrade in cron) more easy than Debian.

                  Regarding the point of uid313's posting, if there is a security bug in Debian or the Linux kernel, everybody can see how long the vulnerability existed, how it came to be and who was responsible. Also it is sometimes possible to tell whether it was neglect, ignorance or malicious intent which caused the bug.

                  Comment


                  • #10
                    Originally posted by chithanh View Post
                    Classy. Actually, no distribution makes fire-and-forget security (dist-upgrade in cron) more easy than Debian.
                    If that's your idea of server administration, then I must say you need to rethink. dist-upgrade needs oversight and a check on what processes still use the old deleted files.

                    Regarding the point of uid313's posting, if there is a security bug in Debian or the Linux kernel, everybody can see how long the vulnerability existed, how it came to be and who was responsible. Also it is sometimes possible to tell whether it was neglect, ignorance or malicious intent which caused the bug.
                    Placing blame is actually stronger in corporations than in open source contributors. If I contribute a piece of code and two years later it turns out there's a critical flaw in, well yeah, cry me a river. Mistakes happen. If I'm an employee and make the same mistake, I would care more about making mistakes and not pissing off the QA guys.

                    Comment


                    • #11
                      That I used the term "fire-and-forget" to describe cron driven server administration I thought made clear that this is something I look down upon. Certainly I do not recommend such behaviour. It must be noted however that Debian is the only distro in which this does not immediately lead to disaster and therefore gained some popularity among Debian admins, sadly.

                      Finding out who checked in vulnerable code is not for placing blame, but it allows to check that person's other code contributions for similar problems.

                      Comment


                      • #12
                        Originally posted by chithanh View Post
                        Finding out who checked in vulnerable code is not for placing blame, but it allows to check that person's other code contributions for similar problems.
                        I don't see a difference with closed source development. Same can happen there.

                        Comment


                        • #13
                          For closed source development that check can be done only by a small group of people who have access to the source code. Sometimes (e.g. when an employee/contractor worked for several companies) there might be nobody else who can examine everything.

                          Also, serious security vulnerabilities sometimes remain unfixed or are silently fixed in closed source code after the vendor becomes aware of them, something which open source projects usually cannot afford.

                          Comment


                          • #14
                            "Sometimes" this and "sometimes" that. There are a lot of "sometimes" for open software too. What is true is that QA needs to happen correctly for both open as well as closed source software. And "sometimes" this doesn't happen for either.

                            Just because a bug was found in a closed source program doesn't prove anything. Lots of bugs are found in open projects too. In the Linux kernel, problems are very often not disclosed at all until the fix is in place. There's a whole business right now around keeping Linux bugs secret up until the patches are developed and go live.
                            Last edited by RealNC; 04-12-2012, 12:19 PM.

                            Comment


                            • #15
                              Originally posted by RealNC View Post
                              "Sometimes" this and "sometimes" that. There are a lot of "sometimes" for open software too. What is true is that QA needs to happen correctly for both open as well as closed source software. And "sometimes" this doesn't happen for either.
                              The "sometimes" is different in Open Source and closed source.

                              Just because a bug was found in a closed source program doesn't prove anything. Lots of bugs are found in open projects too. In the Linux kernel, problems are very often not disclosed at all until the fix is in place. There's a whole business right now around keeping Linux bugs secret up until the patches are developed and go live.
                              The fact is Open Source is more secure by its nature and it's even true when there's exactly the same number of security flaws found in Open Source and closed source project. The reason of this is everyone can check if there are security flaws in Open Source projects, so nobody can hide anything (but some smart guys can keep them in secret till someone else discovers the flaw) and in closed source world just very limited number of people can check the code - so the chance to discover the flaw is lower. To sum this up:

                              10 holes in Windows is more than 10 holes in Linux, because there's lesser probability to discover a flaw in closed source software. PS. Ignore popularity, because those are just examples of Open and closed source software.
                              Last edited by kraftman; 04-12-2012, 02:20 PM.

                              Comment

                              Working...
                              X