Slashdot Mirror

Show me an OS with more than 1% market that has a kernel and network stack that is not written in C/C++.

I'd argue that's bad too. (Some sample evidence: Linux kernel buffer overflow (2013). Linux KVM buffer overflow (2013). Remote Linux buffer overflow that could potentially lead to arbitrary code execution (2014). Integer overflow seemingly leading to buffer overflow in FreeBSD (2013). Windows 8 double free vulnerability (2014). etc.) There needs to be a small kernel of code that is in something very low-level, but honestly most of what is in current OS "kernels" (and I don't think that term applies to a piece of software with tens of millions of lines of code) doesn't have to be. Java isn't the right thing and maybe you don't even want something GC'd, but I also think C isn't either.

It's not entirely clear what you mean when you say "root exploit" but one interpretation is an exploit that when run as a regular user gives you administrator/root permissions. There have definitely been recent XP privilege escalations exploits for XP recently (e.g. CVE-2013-5065 leverages a bug in NDProxy).

Perhaps you meant "remote exploit" but also last year there was CVE-2013-3175 malformed asynchronous RPC request so another machine can attack your XP machine over the network with no user intervention. See this table of 2013 Windows XP CVE entries for a list of what MS have been patching...

If you are no longer able to keep your OS regularly patched it's no longer safe and you are better off using something else for online activities. Save XP for those appliances that have to use it and can be stringently firewalled/quarantined.

It's not entirely clear what you mean when you say "root exploit" but one interpretation is an exploit that when run as a regular user gives you administrator/root permissions. There have definitely been recent XP privilege escalations exploits for XP recently (e.g. CVE-2013-5065 leverages a bug in NDProxy).

Perhaps you meant "remote exploit" but also last year there was CVE-2013-3175 malformed asynchronous RPC request so another machine can attack your XP machine over the network with no user intervention. See this table of 2013 Windows XP CVE entries for a list of what MS have been patching...

If you are no longer able to keep your OS regularly patched it's no longer safe and you are better off using something else for online activities. Save XP for those appliances that have to use it and can be stringently firewalled/quarantined.

It looks from the video that the password is simply the username concatenated with a global string, "123456".

That's not salt. That's not what the word means. A salt is data that is not part of the password but is combined with the password when hashed. The client side never sees salt.

So all these discussions of salt are not at all relevant.

This is fundamentally a case of hard-coded credentials, which is more stupid than a non-random salt. (Also, really, transmitting credentials over HTTP?)

I was wondering about that too -- from the description it didn't sound like a salt, I thought the summary was inaccurate (nearly unheard of on Slashdot!), but TFA said the same thing.

Sounds like someone knew enough about cryptography to be dangerous and though that any random (or not) string added to the plaintext password is a salt.

It looks from the video that the password is simply the username concatenated with a global string, "123456".

That's not salt. That's not what the word means. A salt is data that is not part of the password but is combined with the password when hashed. The client side never sees salt.

So all these discussions of salt are not at all relevant.

This is fundamentally a case of hard-coded credentials, which is more stupid than a non-random salt. (Also, really, transmitting credentials over HTTP?)

The important write protects are whether the BIOS configures itself as locked or not after it's booted far enough to determine there are no BIOS updates pending. You can check if your BIOS is open or closed to attackers by running Copernicus or Chipsec.

There are so many categories with huge number of bugs that I don't know if I'd go so far as to say input validation is "most" security bugs. It is, however, one giant source of bugs.

Some of them are delightfully subtle, like the one discussed above: "I didn't think a CA would just issue a cert that had a null in the string!" Hey, the data format uses length-counted strings, not C strings. Don't pretend they're also going to be C strings.

Input validation is consistently in any Top N list of security-related programming mistakes.

As far as I can see, they do not rely on a specific IE vulnerability for inserting the payload, but they rely on a specific (and fixed) Windows vulnerability to bypass ASLR, which is a crucial component of EMET. They claim in a footnote that the "IE flaw could be modified to leak the base address of a DLL in another way", but they do not provide a working exploit that does so.

#BadBIOS - BIOS Malware

#

- Copernicus: Question Your Assumptions about BIOS Security

http://www.mitre.org/capabilities/cybersecurity/overview/cybersecurity-blog/copernicus-question-your-assumptions-about

- "Seems to have a BIOS hypervisor, SDR functionality that bridges air gaps, wifi card removed."

https://twitter.com/dragosr/status/388512915742937089

=

- #BadBIOS

https://twitter.com/search?q=%23BadBIOS

=

- "More on my ongoing chase of #badBIOS malware."

https://plus.google.com/103470457057356043365/posts/9fyh5R9v2Ga
https://plus.google.com/103470457057356043365

=

- Nobody Seems To Notice and Nobody Seems To Care: Government & Stealth Malware

http://slexy.org/view/s2otvoDuKW

=

- Gpu based paravirtualization rootkit, all os vulne

http://forum.sysinternals.com/gpu-based-paravirtualization-rootkit-all-os-vulne_topic26706.html

=

- #badBIOS (and lotsa paranoia, plus fireworks)

https://kabelmast.wordpress.com/2013/10/23/badbios-and-lotsa-paranoia-plus-fireworks/

=

- Air-Gap-Breaching BIOS Rootkits with SDRs Inside (and smartphones, Snowden, NSA, Wikileaks)

"A little while back I covered a paper on FPGAs that could turn themselves into SDRs. I suspected this would be one way to breach an air gap.

It seems I was right on the money. If a little behind the times.

Researchers have found an incredibly persistent BIOS rootkit in the wild that includes SDR functionality⦠literally turning your computer into a radio transmitter to exfiltrate data even if youâ(TM)re not connected to the Internet." [..]

"The researchers were using a new tool, Copernicus, which sadly seems to be Windows-only. Nevertheless a number of you might be interested in checking it out.

There is one enduring mystery of this rootkit⦠how does it survive BIOS reflashes?" [..]

https://kabelmast.wordpress.com/2013/10/11/air-gap-breaching-bios-rootkits-with-sdrs-inside-and-smartphones-snowden-nsa-wikileaks/

https://twitter.com/dragosr/status/388511686744764416

- IMHO Copernicus is the most important security tool in recent history. Already found persistent BIOS malware (survives reflashing) here.

Or MITRE

#BadBIOS - BIOS Malware

#

- Copernicus: Question Your Assumptions about BIOS Security

http://www.mitre.org/capabilities/cybersecurity/overview/cybersecurity-blog/copernicus-question-your-assumptions-about

- "Seems to have a BIOS hypervisor, SDR functionality that bridges air gaps, wifi card removed."

https://twitter.com/dragosr/status/388512915742937089

=

- #BadBIOS

https://twitter.com/search?q=%23BadBIOS

=

- "More on my ongoing chase of #badBIOS malware."

https://plus.google.com/103470457057356043365/posts/9fyh5R9v2Ga
https://plus.google.com/103470457057356043365

=

- Nobody Seems To Notice and Nobody Seems To Care: Government & Stealth Malware

http://slexy.org/view/s2otvoDuKW

=

- Gpu based paravirtualization rootkit, all os vulne

http://forum.sysinternals.com/gpu-based-paravirtualization-rootkit-all-os-vulne_topic26706.html

=

- #badBIOS (and lotsa paranoia, plus fireworks)

https://kabelmast.wordpress.com/2013/10/23/badbios-and-lotsa-paranoia-plus-fireworks/

=

- Air-Gap-Breaching BIOS Rootkits with SDRs Inside (and smartphones, Snowden, NSA, Wikileaks)

"A little while back I covered a paper on FPGAs that could turn themselves into SDRs. I suspected this would be one way to breach an air gap.

It seems I was right on the money. If a little behind the times.

Researchers have found an incredibly persistent BIOS rootkit in the wild that includes SDR functionality⦠literally turning your computer into a radio transmitter to exfiltrate data even if youâ(TM)re not connected to the Internet." [..]

"The researchers were using a new tool, Copernicus, which sadly seems to be Windows-only. Nevertheless a number of you might be interested in checking it out.

There is one enduring mystery of this rootkit⦠how does it survive BIOS reflashes?" [..]

https://kabelmast.wordpress.com/2013/10/11/air-gap-breaching-bios-rootkits-with-sdrs-inside-and-smartphones-snowden-nsa-wikileaks/

https://twitter.com/dragosr/status/388511686744764416

- IMHO Copernicus is the most important security tool in recent history. Already found persistent BIOS malware (survives reflashing) here.

https://twitter.com/dragosr/status/388512915742937089

- and thatâ(TM)s not even interesting part. Seems to have a BIOS hypervisor, SDR functionality that bridges air gaps, wifi card removed.

https://twitter.com/dragosr/status/388521551693217792

- Copernicus BIOS verification. Also if tool is mysteriously failing or weird output full of FFs you may have problem. http://goo.gl/AHLwbD

https://twitter.com/dragosr/status/388534580493287424

- This particular BIOS persistent malware sample seems use TLS encrypted DHCP HostOptions as a command and control.

https://twitter.com/drago

MITRE could've easily done this, provided it wasn't micromanaged.

To expand further on this, it is a violation of CWE-257 to store a much wider hash than the passwords entropy.

"The storage of passwords in a recoverable format makes them subject to password reuse attacks by malicious users."

Storing a 128-bit hash of a typical password, due to their much lower entropy, is in fact storing it in a recoverable format.

Of course you can add a prefix to each vendor and therefore allow them to share a larger bug address space. The simplest scheme is to make RedHat bugs RH-xxxxxx, Debian ones DE-xxxxxx, etc. The shared allocation approach taken by CVE numbering could be used too. I would call that a combined or aggregated stream of bug numbers rather than a single stream; that's a hair splitting distinction though.

Regardless, to be effective for tracking regular bugs and features, you would also need resources to coordinate things like tagging duplicates across vendors. A Linux bug might be upstream of ten different distribution bugs. When it's fixed in the kernel, which bug number should the commit refer to?

With a complicated enough mapping of vendor bug number to kernel bug number, you could try to capture this information too. That's another shared resource someone needs to maintain though. It's overhead with little perceived value to the individual vendors involved. Linux distributors are motivated to get bug fixes pushed upstream. There's a benefit in it for them. There's little benefit for any one vendor to having a universal bug number mapping tracker, relative to the complexity you'd need to maintain a useful one. Even if you had most of the major distributions agreeing on the shared numbering scheme, there's also time needed to coordinate the bug ids for contributions to the project outside of those vendors.

The number of CVE incidents is low enough (and the issues serious enough) that the bug id mapping they do is not a serious drag on development. One of the reasons the Linux kernel can innovate at a high rate is because it's not burdened by this sort of management issue most of the time.

cve.mitre.org for your CVE searching.

Splatting TIFF images is a complicated matter. They're more than just mundane dumps of pixel data. In addition to just storing the image data itself, they can hold many kinds of metadata, be compressed in many ways, and all encoded in either big-endian or little-endian byte order. Any of those features might trigger vulnerable code in a parser, which might allow a buffer overflow or other vulnerability. This is similar to problems with every other complex format out there, (in)famously including JPEG and TrueType, to name a few.

From reading TFA, it looks like the server itself is vulnerable because it processes the TIFF fully before it's re-encoded to be sent to the mobile devices. There are two vulnerabilities, both of which are buffer overflows.

Splatting TIFF images is a complicated matter. They're more than just mundane dumps of pixel data. In addition to just storing the image data itself, they can hold many kinds of metadata, be compressed in many ways, and all encoded in either big-endian or little-endian byte order. Any of those features might trigger vulnerable code in a parser, which might allow a buffer overflow or other vulnerability. This is similar to problems with every other complex format out there, (in)famously including JPEG and TrueType, to name a few.

From reading TFA, it looks like the server itself is vulnerable because it processes the TIFF fully before it's re-encoded to be sent to the mobile devices. There are two vulnerabilities, both of which are buffer overflows.

Nor will Warner Bros., given the name of one of the projects involved in this effort:

I think the Serval Project would have more right to be concerned, given that it is their work that's being hidden behind the advertising-ridden link from TFA.

It's also unsettling that work from a community project, intended to improve communications for people in need, is in the process of being "embraced" by an organisation like Mitre, funded by, and heavily tied into US Government and military.

Ad-hoc mesh networks do have the potential to be a game changer in a number of arenas. US government involvement this early is a bad sign for their future.

This whole thing about Java being the issue annoys me - if you take a broader look at the whole ecosystem.

Take a look at no more than 2 weeks ago with CVE-2012-4414 for example...

This is a MySQL security bug where any authorised DB user can arbitrarily inject SQL in the binlog used for replication...

For those that don't know Oracle has recently (over the past year) moved the majority of their bugs database internal only so that inhibits discussions for a start and on top of that they no longer publish test cases for fixes ... it looks like they might be going into an internal/tests directory but that isn't provided in the GPL tarball they provide.

However the curiousness doesn't stop there - if they are still writing test cases for code as opposed to just changing stuff willynilly they don't seem to be writing them very well.

When the Percona guys were merging from the upstream code they used the test case that the MariaDB team put together for this CVE - since there is no test provided by Oracle as previously mentioned.

They naturally expected the test to be fine seeing as Oracle claimed the CVE was fixed in 5.5.29 but shock horror it failed.

They ended up merging the MariaDB fix instead.

Given that what makes you think the rest of the code is *really* like and why that Java fix recently introduced a new bug and so on...

Ah well in the meantime FESCO has accepted the proposal to replace MySQL with MariaDB in Fedora 19 which is something that Oracle weren't too pleased with...

That Oracle response was prior to the FESCO vote by the way - time to get the popcorn methinks!

who cares if it was somehow compromised

People who know about exploits like CVE-2009-1244 and similar vulnerabilities?

You do have a good point -- namely that the enterprise of creating all the hardware necessary for a single computer is just too much for any one person to reasonably accomplish and still be productive at whatever their day job happens to be. With that in mind, it would probably be wise to create some kind of risk profile for the various aspects of computer security -- address the gaping holes before you start worrying about the really difficult exploits.

I've asked this question before and the answers I get usually refer me to really simple instructions for technically illiterate types:
* don't click on sketchy links in email messages
* pick a good password
* install antivirus software
* use a firewall

Does anyone know where to find good stats on attack vectors? Something like this, but which also quantifies hardware and social engineering risks: http://cwe.mitre.org/data/index.html

Also, unlike Wordpress, Drupal does a pretty good job keeping up security.

Evidence/proof please? I don't really see them as being significantly better:
http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=joomla
http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=drupal
http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=wordpress
http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=plone
http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=django
OK they only had 5 sql injection CVEs in 2012 while Wordpress had 6. But "pretty good job" doesn't seem to spring to mind when I look at the Drupal CVEs.

Also, unlike Wordpress, Drupal does a pretty good job keeping up security.

Evidence/proof please? I don't really see them as being significantly better:
http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=joomla
http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=drupal
http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=wordpress
http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=plone
http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=django
OK they only had 5 sql injection CVEs in 2012 while Wordpress had 6. But "pretty good job" doesn't seem to spring to mind when I look at the Drupal CVEs.

Also, unlike Wordpress, Drupal does a pretty good job keeping up security.

Evidence/proof please? I don't really see them as being significantly better:
http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=joomla
http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=drupal
http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=wordpress
http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=plone
http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=django
OK they only had 5 sql injection CVEs in 2012 while Wordpress had 6. But "pretty good job" doesn't seem to spring to mind when I look at the Drupal CVEs.

Also, unlike Wordpress, Drupal does a pretty good job keeping up security.

Evidence/proof please? I don't really see them as being significantly better:
http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=joomla
http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=drupal
http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=wordpress
http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=plone
http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=django
OK they only had 5 sql injection CVEs in 2012 while Wordpress had 6. But "pretty good job" doesn't seem to spring to mind when I look at the Drupal CVEs.

Also, unlike Wordpress, Drupal does a pretty good job keeping up security.

Evidence/proof please? I don't really see them as being significantly better:
http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=joomla
http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=drupal
http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=wordpress
http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=plone
http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=django
OK they only had 5 sql injection CVEs in 2012 while Wordpress had 6. But "pretty good job" doesn't seem to spring to mind when I look at the Drupal CVEs.

My argument on point 1 is that it's hardly unusual for 4-year computer science program to expose students to low-level code (and demand they write some low-level code). You show a developer who mostly writes in Python some C or assembler and there's a good chance they'll understand what they're looking at.

Regarding point 2, the specific phenomenon that I'm going to focus on is classic buffer overflows, because those still are some of the most common forms of attack (see CWE-120). In C, a programmer has to be very careful to manage their malloc's and C arrays (particularly stack-allocated arrays) and pointers in general to ensure that they can't walk off the end of a data structure or point to their own running code or stuff 1100 bytes into a 1000-byte spot in memory. In, say, Python, because the interpreter has had a lot of checking for this, and because the structures in C that allow these kind of vulnerabilities aren't available directly, they're a non-issue. The scripting language interpreter / compiler solves that problem once for you, and then you don't have to solve it again. And the effect is that higher-level applications tend to be more vulnerable to application-layer mistakes like SQL injection than they are buffer overflows.

Well, I had a quick look at some other CVEs for the hell of it.

Mozilla:
CVE-2012-3980 - 48 days - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3980 (Bugzilla entry concealed from public)
CVE-2012-3979 - 48 days - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3979 (Bugzilla entry concealed from public)
CVE-2012-3968 - 48 days - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3968 (Bugzilla entry concealed from public)

Google:
CVE-2012-2869 - 103 days - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2869 (Bug tracker issue concealed from public)
CVE-2012-2864 - 94 days - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2864 (Bug tracker issue concealed from public)
CVE-2012-2859 - 73 days - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2859 (Bug tracker issue concealed from public)

So, Microsoft is not unique in sucking at getting patches out promptly. It's pretty abundantly clear that "Marc" is just another anti-Microsoft shill ranting about how Microsoft perpetuated every evil in history. (Really, if Open Source is the paragon of transparency, why are all of the bug tracker entries detailing these now fixed bugs private?)

Well, I had a quick look at some other CVEs for the hell of it.

Mozilla:
CVE-2012-3980 - 48 days - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3980 (Bugzilla entry concealed from public)
CVE-2012-3979 - 48 days - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3979 (Bugzilla entry concealed from public)
CVE-2012-3968 - 48 days - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3968 (Bugzilla entry concealed from public)

Google:
CVE-2012-2869 - 103 days - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2869 (Bug tracker issue concealed from public)
CVE-2012-2864 - 94 days - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2864 (Bug tracker issue concealed from public)
CVE-2012-2859 - 73 days - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2859 (Bug tracker issue concealed from public)

So, Microsoft is not unique in sucking at getting patches out promptly. It's pretty abundantly clear that "Marc" is just another anti-Microsoft shill ranting about how Microsoft perpetuated every evil in history. (Really, if Open Source is the paragon of transparency, why are all of the bug tracker entries detailing these now fixed bugs private?)

Well, I had a quick look at some other CVEs for the hell of it.

Mozilla:
CVE-2012-3980 - 48 days - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3980 (Bugzilla entry concealed from public)
CVE-2012-3979 - 48 days - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3979 (Bugzilla entry concealed from public)
CVE-2012-3968 - 48 days - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3968 (Bugzilla entry concealed from public)

Google:
CVE-2012-2869 - 103 days - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2869 (Bug tracker issue concealed from public)
CVE-2012-2864 - 94 days - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2864 (Bug tracker issue concealed from public)
CVE-2012-2859 - 73 days - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2859 (Bug tracker issue concealed from public)

So, Microsoft is not unique in sucking at getting patches out promptly. It's pretty abundantly clear that "Marc" is just another anti-Microsoft shill ranting about how Microsoft perpetuated every evil in history. (Really, if Open Source is the paragon of transparency, why are all of the bug tracker entries detailing these now fixed bugs private?)

Well, I had a quick look at some other CVEs for the hell of it.

Mozilla:
CVE-2012-3980 - 48 days - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3980 (Bugzilla entry concealed from public)
CVE-2012-3979 - 48 days - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3979 (Bugzilla entry concealed from public)
CVE-2012-3968 - 48 days - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3968 (Bugzilla entry concealed from public)

Google:
CVE-2012-2869 - 103 days - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2869 (Bug tracker issue concealed from public)
CVE-2012-2864 - 94 days - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2864 (Bug tracker issue concealed from public)
CVE-2012-2859 - 73 days - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2859 (Bug tracker issue concealed from public)

So, Microsoft is not unique in sucking at getting patches out promptly. It's pretty abundantly clear that "Marc" is just another anti-Microsoft shill ranting about how Microsoft perpetuated every evil in history. (Really, if Open Source is the paragon of transparency, why are all of the bug tracker entries detailing these now fixed bugs private?)

Well, I had a quick look at some other CVEs for the hell of it.

Mozilla:
CVE-2012-3980 - 48 days - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3980 (Bugzilla entry concealed from public)
CVE-2012-3979 - 48 days - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3979 (Bugzilla entry concealed from public)
CVE-2012-3968 - 48 days - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3968 (Bugzilla entry concealed from public)

Google:
CVE-2012-2869 - 103 days - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2869 (Bug tracker issue concealed from public)
CVE-2012-2864 - 94 days - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2864 (Bug tracker issue concealed from public)
CVE-2012-2859 - 73 days - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2859 (Bug tracker issue concealed from public)

So, Microsoft is not unique in sucking at getting patches out promptly. It's pretty abundantly clear that "Marc" is just another anti-Microsoft shill ranting about how Microsoft perpetuated every evil in history. (Really, if Open Source is the paragon of transparency, why are all of the bug tracker entries detailing these now fixed bugs private?)

Well, I had a quick look at some other CVEs for the hell of it.

Mozilla:
CVE-2012-3980 - 48 days - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3980 (Bugzilla entry concealed from public)
CVE-2012-3979 - 48 days - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3979 (Bugzilla entry concealed from public)
CVE-2012-3968 - 48 days - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3968 (Bugzilla entry concealed from public)

Google:
CVE-2012-2869 - 103 days - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2869 (Bug tracker issue concealed from public)
CVE-2012-2864 - 94 days - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2864 (Bug tracker issue concealed from public)
CVE-2012-2859 - 73 days - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2859 (Bug tracker issue concealed from public)

So, Microsoft is not unique in sucking at getting patches out promptly. It's pretty abundantly clear that "Marc" is just another anti-Microsoft shill ranting about how Microsoft perpetuated every evil in history. (Really, if Open Source is the paragon of transparency, why are all of the bug tracker entries detailing these now fixed bugs private?)

Prove what, specifically? If you're going to be a dick, you should be specific about it. But here's a recent example.

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3965

The CVE was created on July 11th, 2012.

Didn't you said: "Mozilla, Red Hat, Canonical, Google..." ?
So, if you comment should hold any value, then where's one from Red Hat, Canonical and of course Google?
(I don't care about the "Everyone does it". Since that's really tough to prove... or do you know of any CVE that
has been neglected for any stuff that comes standard with OpenBSD default installation?)

Prove what, specifically? If you're going to be a dick, you should be specific about it. But here's a recent example.

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3965

The CVE was created on July 11th, 2012. However, the existence of the flaw were not announced until August 29th, 2012.

There are many many more, and I will leave it as an exercise for anyone that wants more proof. Just look at the date the CVE was created (the assigned date) and look at the date of the announcement.

Except that Apple have never even installed Java 7 to be vulnerable.. this is update to their Java 6, so the story is bogus.

It's oracles job to handle Java 7 on mac, Apple are only dealing upto 6.

Those vulnerabilities exist in Java 6 as well, and if what you're saying is true then why are they fixing this this vulnerability in the bugfix?

The bug described in CVE-2012-4681 affects Java SE 7. OS X uses Java SE 6. It would be a little weird if they patched Java SE 6 for a bug that doesn't exist in Java SE 6.

Yeah, or even more "efficiently" than you ever would have dreamt...
http://cwe.mitre.org/data/definitions/14.html

What was your password again?

Yeah, just like http://cwe.mitre.org/data/definitions/14.html

Don't forget that the US Department of Homeland Security maintains a giant list of security flaws. It's called the Common Vulnerabilities Enumeration.

Check the fine print at the bottom of the page: "CVE is co-sponsored by the National Cyber Security Division of the U.S. Department of Homeland Security."

So that means the government doesn't even need to go looking for holes - security companies send them to the government directly to be listed!

No mole required, just a "friendly" email informing them that they're going to keep silent for a bit and "forgetting" to post the alert publicly.

CVE doesn't work that way. From the FAQ:

Isn’t CVE just another vulnerability database?

No. CVE is not a vulnerability database. CVE is designed to allow vulnerability databases and other capabilities to be linked together, and to facilitate the comparison of security tools and services. As such, CVE does not contain information such as risk, impact, fix information, or detailed technical information. CVE only contains the standard identifier number with status indicator, a brief description, and references to related vulnerability reports and advisories.

The project arose because different vendors were assigning different names and ids to vulnerabilities and generally just confusing the hell out of everyone. CVE just provides a standard id that all of the different security researchers can use to refer to the same issue.

In practice, researchers typically contact MITRE or other software vendors participating in the program to obtain a CVE ID, possibly before the assessment of the vulnerability is complete. Then they announce it themselves with the CVE ID and send a note to MITRE letting them know that the vulnerability is now public. MITRE then updates the CVE website with information about the vulnerability. If the government did want to restrict information about a security vulnerability they'd need to convince the security researcher not to announce it at all, just omitting it from the database wouldn't be enough.

Don't forget that the US Department of Homeland Security maintains a giant list of security flaws. It's called the Common Vulnerabilities Enumeration.

Check the fine print at the bottom of the page: "CVE is co-sponsored by the National Cyber Security Division of the U.S. Department of Homeland Security."

So that means the government doesn't even need to go looking for holes - security companies send them to the government directly to be listed!

No mole required, just a "friendly" email informing them that they're going to keep silent for a bit and "forgetting" to post the alert publicly.

Well, duh. One of those is a criminal breaking into systems. The other was a company that was the victim of a crime. We also don't charge people who get their houses broken into with crimes yet we do for the person breaking into another person's house.

Your analogy is broken. In this case, it is more like blaming the bank which was robbed. You blame them not for the fact that is was robbed, but that inadequate security measures (like this) were put in place to protect your money.

Since online transactions seemed to be their business, they should have made sure that it is next to impossible to leak the data. Most lilkely a lot of corners were cut to maximize profits. I have no idea what was exploited to get the data, but I am quite sure that it can be found here

I'm not sorry. You posted a public comment and I replied publicly. Cross-site scripting and privacy aren't "internet bogeymen", they're realistic concerns that transcend how secure the office in your house is.

2011 CWE/SANS Top 25 Most Dangerous Software Errors shows cross-site scripting at #4 and cross-site request forgery at #12, bugs that big sites like Facebook have been vulnerable to.

And while lots of people are apathetic, there are plenty of those who care about privacy.

It cannot "be exploited remotely to execute arbitrary code". It can only crash the service. There is no RCE developed for this vulnerability, yet.

As the CVE says:

The Remote Desktop Protocol (RDP) implementation in [...] does not properly process packets in memory, which allows remote attackers to execute arbitrary code by sending crafted RDP packets triggering access to an object that (1) was not properly initialized or (2) is deleted, aka "Remote Desktop Protocol Vulnerability."

And the MS security bulletin also holds it as Maximum Security Impact: Remote Code Execution.

This is not FUD, even if there is no worm completed yet, it is a clear failure of MS security, and their concept of many lines of defense. Also, they promised to implement their own rehash of W^X, but apparently failed.

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3402

'Unspecified vulnerability in the Win32k TrueType font parsing engine in the kernel in Microsoft Windows XP SP2 and SP3, Windows Server 2003 SP2, Windows Vista SP2, Windows Server 2008 SP2, R2, and R2 SP1, and Windows 7 Gold and SP1 allows remote attackers to execute arbitrary code via crafted font data in a Word document, as exploited in the wild in November 2011'
Just don't use MS software on an MS OS and you should be fine. Or tune up your anti-virus to include dodgy fonts

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3368

There has not been a single remote-root exploit in BIND9 since it was offered up to the world circa 2001. It was a complete rewrite with new goals, so taking BIND 4.x or BIND 8.x as examples isn't really relevant.

ISC is also completely open about security issues, listing them all on the web site and registering them with the CVE Registry.

As I stated in another post, the goal of BIND9 was use use various constructs (like assertions) to check data integrity, where possible on the fly and where not practical in a way that causes a core dump. That to fail safe was the best option, and crashing in a way the bug could be fixed was a positive. If you view the advisories against BIND9 you'll see that strategy has worked very well. Of course there's no reason not to lock any application in a VM, jail, chroot or whatever to get additional security, but I think the track record of BIND9 compared to most other major open source software is decent.

BIND is also "full featured". Many of the folks here reference alternatives like NSD, tinyDNS, or Unbound which provide limited functionality compared to BIND. Obviously if you're willing to limit the functionality you limit the bug exposure, but that's true both if you use software that doesn't include the functionality but also if you disable that functionality in BIND. For instance the bug in question affects recursive resolvers only, if your BIND9 instance is an authority only configuration there is no exposure.

I'm afraid most of BIND's bad reputation comes from BIND 4.x and BIND 8.x, both of which were quite bad (for different reasons). BIND9 was a departure, and now ISC is working on BIND 10, which should be yet another large leap forward.

While your point is valid, that a reader should not write, you misunderstand vulnerabilities. Yes it could be sandboxed, but it isn't.

If a program loads Win32 API libraries, which it pretty much has to to run under Windows, the code to write and modify is already loaded and available. A small vulnerability can allow malicious code to call the write functions, and it doesn't take much code to do that.

This is why simply having the Explorer interface show icons of the app lead to a critical vulnerability. Load an icon, fail to handle buffer overflow, and arbitrary code is now running on your computer.

http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1049

Security updates. http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=android - There are 89 CVE entries or candidates that match your search.

This photo http://www.mitre.org/about/photo_archives/photos/low_res/whirlwind_f5001.jpg is begging for a larger than life teapot.