US-CERT Shows the Value of FLOSS

A US-CERT notice of vulnerability to many systems running many OS on Intel 64-bit processors shows the value of FLOSS:

  • for years Wintel systems were vulnerable to privilege escalation attacks due to a flaw in Intel 64-bit CPUs,
  • notified in early May of the flaw, M$ took a month to push out an update compensating for the flaw, and
  • Debian took 2 days to fix the flaw.

Once again the importance of diversity in IT is shown. Relying on M$ and Intel for all your IT is a recipe for disaster. It is only luck that prevented the collapse of IT as we know it had cyber-whatnots found the vulnerability first. Eventually, that will happen. When it does, having Wintel running IT will be your worst nightmare. What’s running your IT?

I recommend Debian GNU/Linux. It will work for you.

see US-CERT Vulnerability Note VU#649219 – SYSRET 64-bit operating system privilege escalation vulnerability on Intel CPU hardware.

About Robert Pogson

I am a retired teacher in Canada. I taught in the subject areas where I have worked for almost forty years: maths, physics, chemistry and computers. I love hunting, fishing, picking berries and mushrooms, too.
This entry was posted in technology. Bookmark the permalink.

13 Responses to US-CERT Shows the Value of FLOSS

  1. oiaohm says:

    http://secunia.com/vulnerability_review/vulnerability_review_request/ This is a good report if you want windows.

    Also Tdr someone has to be wrong.

    http://www.gfi.com/blog/wp-content/uploads/2013/02/Most-Targeted-Operating-Systems-in-2012.jpg

    http://www.gfi.com/blog/report-the-most-vulnerable-operating-systems-and-applications-in-2012/

    Tdr that is raw National Vulnerability Database (NVD)) processed into graphics. The mandatory reporting. Not the optional reporting.

    Also over that time frame there were more than 2 zero day flaws per OS.

    What zdnet has read is cherry picking CVE numbers to get the numbers they want. There should be about 15 to 20 zero-days each OS.

    2 and 3. That is like walking up to 2 people and asking what there favourite cake is. Then saying the race of those people only eat those cakes. No question false.

  2. oiaohm says:

    Tdr you have to allow Linux kernel includes most of the system drivers. There are bugs in third party drivers on Windows that have not been fixed for 10+ years. Some are particular bad allowing you to take control of a system just by inserting a custom set-up USB key.

    Yes denial of service is lower down the Linux kernel fix list. Yes its a zero day attack but its not effective. You hit it you stop the system you steal no data.

    Every year we see these reports. Please note denial of service bugs in Windows normally don’t get a CVE number. Reason why denial of service get a CVE number with Linux is the Linux kernel reports them.

    Part of the problem there is no fixed rule on what bugs have to be reported and have a CVE issued.

    Cert is just a recording site of reported issues. Yes the HFS driver for windows has had issues as well in the same time frame. Yet you don’t see that on Cert.

    Tdr Cert is not a good quality source to attempt to compare secuirty.

  3. 4 times as many vulnerabilities for half as long seems like twice the vulnerability to me… Then there is the average CVSS score… Then there are the number of attackers… I’ll stick with GNU/Linux, thank you.

    The Linux vulnerabilities listed as “0-day”:

    • CVE-2012-2100 is a correction to the fix detailed in CVE-2009-4307, which did not fully work on the common x86 platform. Trustwave considered this a zero-day due to availability of exploit information from the time of the original patch.
    • CVE-2012-2319 is a follow-up to CVE-2009-4020; issues in the HFS file system were detailed and patched on Dec. 3, 2009, but HFSPlus was left vulnerable until May 4, 2012.

    OMG! HFS! How many millions of servers running GNU/Linux actually use HFS???

    CVE-2009-4307:
    “The ext4_fill_flex_info function in fs/ext4/super.c in the Linux kernel before 2.6.32-git6 allows user-assisted remote attackers to cause a denial of service (divide-by-zero error and panic) via a malformed ext4 filesystem containing a super block with a large FLEX_BG group size (aka s_log_groups_per_flex value).”

    “user-assisted remote attackers”… Hmmm… That’s pretty esoteric for a vulnerability. I’ll take that any day over vulnerabilities like the CVE-2009-3103 “Array index error in the SMBv2 protocol implementation in srv2.sys in Microsoft Windows Vista Gold, SP1, and SP2, Windows Server 2008 Gold and SP2, and Windows 7 RC allows remote attackers to execute arbitrary code or cause a denial of service (system crash) via an & (ampersand) character in a Process ID High header field in a NEGOTIATE PROTOCOL REQUEST packet, which triggers an attempted dereference of an out-of-bounds memory location, aka “SMBv2 Negotiation Vulnerability.” NOTE: some of these details are obtained from third party information.”
    That one was around for years before it was fixed but it still took M$ 9 days to provide a fix after it was public. I’ll trade you an occassional two-years of vulnerability on something esoteric versus 9 days on almost every LAN server on the planet.

  4. Tdr says:

    Linux vendors do on average take longer to fix holes though and Linux distributions have many more vulnerabilities with more days at risk than Microsoft products:

    http://www.zdnet.com/linux-trailed-windows-in-patching-zero-days-in-2012-report-says-7000011326/

  5. oiaohm says:

    Viktor go read the CERT policy please.

    In the 45 days of fault being told to you. You are allowed to patch the fault. You are not allowed to document about the secuirty flaw you are patching. Its just a general fix.

    Now available happens almost instantly on redhat a lot why because the fix just moves from the general fixes repo to the secuirty repo.

    “are now available”. Now available from the secuirty repo for auto secuirty update install of just available by general repo updates.

    Why do what redhat does. If attacker does happen to hit the system straight after the embargo lifts a percent of redhat systems will already be protected.

    “One can embargo the details while releasing the patch.”
    This is correct. The Linux Distributions, AIX and OS X. Embargo the details of the patches yet ship the patches out anyhow.

    “So it does not matter if the fix was finished long before that date, because it was only released on that date.”
    No the redhat patch in the general update repo was release before that date. Then on that date migrated to the secuirty repo for full deployment.

    Yes so question is what release date is important. The secuirty repo or the general repo.

    MS has miss read the US-Cert Rules. Patching by stealth is allowed.

  6. Viktor wrote, Cert gives 45 days so you can attempt to beat that.

    No, you cannot. Otherwise an embargo would be ridiculous”

    One can embargo the details while releasing the patch. That’s SOP. End-users care little about details in any event.

  7. Viktor says:

    Cert gives 45 days so you can attempt to beat that.

    No, you cannot. Otherwise an embargo would be ridiculous, if everybody ignored it. If you look at Red Hat’s bug report which I linked to, you will find that the fix, despite being most likely finished before the deadline, has only been released once the vulnerability was made public on 2012-06-12. So it does not matter if the fix was finished long before that date, because it was only released on that date. The wording in Red Hat’s Security Advisory from 2012-06-12 is unmistakable:

    Updated kernel packages that fix two security issues and multiple bugs are now available for Red Hat Enterprise Linux 5.6 Extended Update Support.

    Not the words: “[…] are now available […].”

  8. Viktor says:

    LOL. Tell that to CERT, not to me. It’s their policy. And Debian also respected the embargo. So you should complain to them, too, if you’ve got a problem with that.

    But let’s keep to the facts and sum up: Microsoft did, in fact, not take longer to issue a fix, contrary to your claim.

    And I wouldn’t be speaking about boats if I were you. Because your boat, carrying your outrageous anti-Microsoft claims, has sunken so often that it’s not even funny anymore.

  9. oiaohm says:

    Viktor really want to point something out important.

    That redhat bug you pointed to Fixed In Version: is blank. Yet the bug mentions a patch as already been sent. The fault in redhat was fixed before the 45 days were up.

    “Yet no company/organization released patches until CERT made the vulnerability public.”
    This is false. Its not only Commercial Linux like Redhat and SUSE that is beating the 45 days regularly. Also out of free Linux distributions Scientific Linux does as well mostly because they share there secuirty team with redhat. OS X and AIX also mostly beat the 45 days as well.

    45 days is that you don’t disclose if you have patched. Not that you cannot patch and say after disclosure that this patch back here in the 45 days addresses the issue this is what you see the all the commercial OS’s bar Microsoft doing regularly.

    Viktor your statement over the 45 days is MS stupid policy over it. Cert gives 45 days so you can attempt to beat that.

  10. If you think having an unpatched vulnerability doesn’t matter, you are a fool. Holes in a boat matter even if the captain is unaware.

  11. Viktor says:

    You don’t seem to understand that CERT has embargoes on their vulnerabilities. As you can see from this bug report, the problem was already known about at the end of April. Yet no company/organization released patches until CERT made the vulnerability public. CERT’s policy is simple: as long as there is no evidence of exploitation, they won’t shorten the default embargo of 45 days. Which means that — yes — companies/organizations basically wait until the embargo is lifted before they issue a fix, and it doesn’t matter whether they could issue it sooner.

  12. “Microsoft Corporation Affected Date notified:01 May 2012 Date updated:08 Jun 2012”

    see http://www.kb.cert.org/vuls/id/649219

    “Debian GNU/Linux Unknown Date:notified:02 May 2012”

    What’s missing in this is when Xen provided the patch. If it was June 12, then how did M$ have a patch days earlier? If it was 02 May than the best that can be said is that Debian is not worse than M$. Either way, people are paying a lot to have a lot of systems highly vulnerable using M$’s stuff. Wintel, despite what oldman and others claim is not the right way to do IT. What would you say if the malware artists had gotten the news before Xen? Oh my, easy privilege escalation on hundreds of millions of systems, even the much-vaunted “7”.

    Xen appears to have had the fix for two months but did not realize the security implications. see http://lists.xen.org/archives/html/xen-devel/2012-06/msg00671.html

  13. Viktor says:

    Too much to drink, Herr Pogson? Debian was also notified at the start of May. How is this 2 days then? Learn to count.

    By the way, after the vulnerability was published on 2012-06-12 Microsoft pushed out an update on 2012-06-13. That would be one day then. If I counted like you.

    And perhaps you should read this:

    http://www.cert.org/kb/vul_disclosure.html

Leave a Reply