Slashdot Mirror

From the "Wizcase" article:

Both the vulnerabilities (dubbed CVE-2018-18472 and CVE-2018-18471) remain unpatched at the time of this publication.

But CVE-2018-18471 and CVE-2018-18472 are not listed at mitre.org or the NIST database:

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-18471
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-18472

From the "Wizcase" article:

Both the vulnerabilities (dubbed CVE-2018-18472 and CVE-2018-18471) remain unpatched at the time of this publication.

But CVE-2018-18471 and CVE-2018-18472 are not listed at mitre.org or the NIST database:

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-18471
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-18472

L(should have)GT: https://research.checkpoint.com/sending-fax-back-to-the-dark-ages/

I attended this talk yesterday, and it was by far the best talk I attended at defcon26. The researchers did some amazing work to get this exploit. You can get the full tail of hackery at the link above, but here's my (probably/mostly correct) summary:
 

• At some point, the fax standard was amended to include support for JPGs, in order to allow full-color faxes
• As the researchers wrote in the above-linked blog article, "For some unknown reason, firmware developers tend to re-implement modules that are already implemented in major popular open sources. This means that instead of using libjpeg [ref.13], the developers implemented their own JPEG parser."
• When the All-in-One device receives a JPG fax, it stores the whole JPG file in local storage (on disk, essentially). This differs from how it processes TIFF files, where the headers and image data are separated. Because the whole JPG file is stored as a normal file, it gives the attacker a platform from which to operate.
• The firmware-developer-implemented JPG parser has a number of bugs, including buffer overflow vulnerabilities in the COM (CVE-2018-5925) and DHT (CVE-2018-5924) markers. It turned out the bug in the DHT marker parser was the easier one to exploit.
• Exploiting the DHT marker parser buffer overflow gets them arbitrary code execution. The code they want to execute is stored in the remainder of the JPG file. Because the OS on these All-in-One devices has no security controls and everything runs with highest privileges, they were able to use this ability to overwrite the LCD screen (to visually prove pwnage) and then to use the Eternal Blue and Double Pulsar (which they managed to squeeze into the ~4000 byte payload they had available in the JPG file) exploits to start attacking other hosts on the network. Since these All-in-One devices tend to be connected to the office network (else, it's hard to print on them), this presents an excellent jumping off point for attacks.

All in all (all-in-one?) this was some amazing research and the full article is well worth a read.

L(should have)GT: https://research.checkpoint.com/sending-fax-back-to-the-dark-ages/

I attended this talk yesterday, and it was by far the best talk I attended at defcon26. The researchers did some amazing work to get this exploit. You can get the full tail of hackery at the link above, but here's my (probably/mostly correct) summary:
 

• At some point, the fax standard was amended to include support for JPGs, in order to allow full-color faxes
• As the researchers wrote in the above-linked blog article, "For some unknown reason, firmware developers tend to re-implement modules that are already implemented in major popular open sources. This means that instead of using libjpeg [ref.13], the developers implemented their own JPEG parser."
• When the All-in-One device receives a JPG fax, it stores the whole JPG file in local storage (on disk, essentially). This differs from how it processes TIFF files, where the headers and image data are separated. Because the whole JPG file is stored as a normal file, it gives the attacker a platform from which to operate.
• The firmware-developer-implemented JPG parser has a number of bugs, including buffer overflow vulnerabilities in the COM (CVE-2018-5925) and DHT (CVE-2018-5924) markers. It turned out the bug in the DHT marker parser was the easier one to exploit.
• Exploiting the DHT marker parser buffer overflow gets them arbitrary code execution. The code they want to execute is stored in the remainder of the JPG file. Because the OS on these All-in-One devices has no security controls and everything runs with highest privileges, they were able to use this ability to overwrite the LCD screen (to visually prove pwnage) and then to use the Eternal Blue and Double Pulsar (which they managed to squeeze into the ~4000 byte payload they had available in the JPG file) exploits to start attacking other hosts on the network. Since these All-in-One devices tend to be connected to the office network (else, it's hard to print on them), this presents an excellent jumping off point for attacks.

All in all (all-in-one?) this was some amazing research and the full article is well worth a read.

Is the point you're trying to make "if you're writing a new web browser, consider Rust for the C-ish parts?"

That's literally what Rust was created for.

If someone is building a new web browser, of course they'll use XUL

You what? Firefox abandoned XUL.

and it makes sense to consider Rust for other parts.

Tha that is precisely what Mozilla is doing right now. They're slowly replacing C++ bit with Rust bits.

Not quite. Most of the comments and questions about Rust, here on Slashdot and many other places, either state or assume that using Rust will magically make your software much safer than other languages.

I think you're wildly exaggerating there.

You mentioned Heartbleed. Heartbleed was an input validation error - as in the input wasn't validated at all.

It was a buffer overflow overflow error triggered by lack of input validation. But if it had been in a memory safe language it would have been a simple DOS attack, not the single biggest security issue of the year.

That's in no way language specific.

Yes it is. How the fuck would heartbleed have allowd you to extract someone else's keys in Python, Java, Haskell, Rust..., well anything other than C or C++? It says here in the CVE that it's a buffer over-read (TIL there was a different term for read vs write in this context):

https://cve.mitre.org/cgi-bin/...

That would not happen in not C or not C++, because other language you know, check bounds and do other things.

Which brings us on to the other topic. Why do people write major bits of infrastructure like SSL libraries and web browsers in unsafe languages like C and C++?

In Rust the function would be called std::ptr::copy_nonoverlapping instead of memcpy - it does the same thing, dump random memory back to the attacker.

Well done! You picked an unsafe function. You can get the same effect in, say, python or Java by using a C module and scribbling all over memory too. Kinf od the point is to stick to safe code. And it's auditable.

The fact you can manage unsafe things in just about any language no matter how hard you try does not mean that C is very unsafe by default and that C++ has quite a number of cases where it's eay to foul up. It's much harder.

Make no mistake: if you manage to do something memory unsafe in Rust you have either subverted it (by explicitly doing unsafe things) or have found a genuine bug.

I didn't say that.

I didn't say you said that, I said you are arguing that. And you are because you kept repeating the point about the number of CVEs only while not taking into account their performance.

I said I study vulnerabilities for a living, full time, and for the last several darn few of them have anything to do with anything Rust would help with.

You seem to think that anything other than C or C++ would not have prevented heartbleed either. I don't know how you can study these things full time not know that. Other languages crash or throw exceptions when overstepping the end of an array. C and C++ don't.

Have a look at the OWASP Top 10 - the most significant types of vulnerabilities that happen nowadays.

That's great and still doesn't invalidate anything I said. Sure you're more likely to make your web application insecure with an injection bug. But if you get a CVE in Chrome, half of everyone on the intire internet is vulnerable in one go.

You seem to be intentionally ignoring the distinction between infrastructure and applications. Rust is and always has been aimed at the same space as C++ (and C[*]). The claim that Rust magically makes your code safe against things inrelated to C++ specifically seems to have been invented by you.

It's possibly you've simply misunderstood people: when people talk about rust being "safe" it's almost always in the context of memry safety and in c

* the first clue is this: https://cve.mitre.org/cgi-bin/... which contains 27 separate and distinct entries, three of them for this year alone. by contrast try searching for "sysvinit" and you get *ONE* entry dating back to 1999.

Most of them are not related to systemd. For example:

NOTE: this does not affect systems, such as default Debian stretch installations, on which Tor startup relies on a systemd unit file (instead of this tor.init script)

Thanks for the bit on mother Theresa. You seem to have your brains together so can you explain what the problems with ststemd are?

caveat: my brain is known to be made of mush, sometimes. as in, some form of dyslexia / delay means i get basic boolean logic wrong, ok? :)

* the first clue is this: https://cve.mitre.org/cgi-bin/... which contains 27 separate and distinct entries, three of them for this year alone. by contrast try searching for "sysvinit" and you get *ONE* entry dating back to 1999. you'd need to start searching for "bash" and start doing a bit more investigation (a bash search refers to several variants) to get a proper comparison.

* the systemd team have been known to ignore bugreports, closing them arbitrarily. not just once but repeatedly. i've seen posts made by people on here which gave references. basically they don't listen to constructive feedback.

* the scope creep on systemd is very insidious and dangerous. there's no consultation about the impact of the changes being made: they're just blithely "handed out" and if you don't like it go fuck yourself is the general attitude. management of firewall rules, fstab, networking, process control: all these things are completely insane to be managed exclusively by PID 1. one mistake and your entire system is compromised (or falls over).

so basically it's down to abdication of responsibility of developers and users to a team that has repeatedly demonstrated a total lack of willingness to recognise and take seriously the responsibility of their role... or more to the point that the distro maintainers *CHOSE WITHOUT CONSULTATION* to forcibly abdicate responsibility on BEHALF of users, the maintenance and running of their system to systemd's developers. if you are not familiar with what happened with the debian "vote": systemd was the absolute worst and least-favoured choice by far and above... and absolutely no explanation as to why that vote was completely and utterly ignored has ever been given.

there are many many articles and examples of why systemd is an extremely dangerous *technical* choice, but mainly it's down to the fact that the users haven't been given any choice - right across the board - due to all major GNU/Linux distros swapping over all at the same time like a flock of birds / shoal of fish. try doing "apt-get --purge remove libsystemd1" and see what happens (or equivalent on fedora, or archlinux). that there *is* no choice is in itself a dangerous precedent (a monoculture).

basically it's really hard to describe.

LD_PRELOAD is not enough for privilege escalation. You need more, like a buggy Microsoft product. Maybe Skype for Linux....

Here's one that was just as bad. Give it up, Linux is not magically more secure than anything else out there. It's less complex, but that's changing.

CVE-2010-3847
elf/dl-load.c in ld.so in the GNU C Library (aka glibc or libc6) through 2.11.2, and 2.12.x through 2.12.1, does not properly handle a value of $ORIGIN for the LD_AUDIT environment variable, which allows local users to gain privileges via a crafted dynamic shared object (DSO) located in an arbitrary directory.

You're the one who's wrong. ARM themselves note that Cortex A57, A72, A75 and A15 processors are affected by CVE-2017-5754 which is the Meltdown CVE (Spectre is CVE-2017-5753 and CVE-2017-5715)

HTML is already a "safe subset" of itself; HTML is merely a markup language. You don't need to implement the DOM or Javascript, especially in an email client.

The problem is, as it has always been, that there are bugs in software that renders HTML.

There have been exploitable bugs in JPEG decoders, PNG decoders, TIFF decoders, GIF decoders, even BMP decoders, BMP being the most braindead simple of image formats: would you say that we need a "safe subset" of image formats?

There have been exploitable bugs text editors. Would you say that we need a "safe subset" of plain text?

It's possible to have bugs in any language, for software decoding any format.

Features don't make for security holes; bad implementations make for security holes, as demonstrated there are bugs in even the simplest, most featureless formats. What you need is better testing.

Sure, every feature multiplies the number of tests, but it's possible to write those tests, if you insist on it, and it's also possible to blow off testing entirely, even if what you've written is simple and featureless, and still have exploitable security holes.

Features, complexity, are not the root cause of security flaws, failing to bring a commensurate amount of testing and rigor is the root cause. Going back to the good old days of less featureful software is not going to fix a damn thing.

HTML is already a "safe subset" of itself; HTML is merely a markup language. You don't need to implement the DOM or Javascript, especially in an email client.

The problem is, as it has always been, that there are bugs in software that renders HTML.

There have been exploitable bugs in JPEG decoders, PNG decoders, TIFF decoders, GIF decoders, even BMP decoders, BMP being the most braindead simple of image formats: would you say that we need a "safe subset" of image formats?

There have been exploitable bugs text editors. Would you say that we need a "safe subset" of plain text?

It's possible to have bugs in any language, for software decoding any format.

Features don't make for security holes; bad implementations make for security holes, as demonstrated there are bugs in even the simplest, most featureless formats. What you need is better testing.

Sure, every feature multiplies the number of tests, but it's possible to write those tests, if you insist on it, and it's also possible to blow off testing entirely, even if what you've written is simple and featureless, and still have exploitable security holes.

Features, complexity, are not the root cause of security flaws, failing to bring a commensurate amount of testing and rigor is the root cause. Going back to the good old days of less featureful software is not going to fix a damn thing.

HTML is already a "safe subset" of itself; HTML is merely a markup language. You don't need to implement the DOM or Javascript, especially in an email client.

The problem is, as it has always been, that there are bugs in software that renders HTML.

There have been exploitable bugs in JPEG decoders, PNG decoders, TIFF decoders, GIF decoders, even BMP decoders, BMP being the most braindead simple of image formats: would you say that we need a "safe subset" of image formats?

There have been exploitable bugs text editors. Would you say that we need a "safe subset" of plain text?

It's possible to have bugs in any language, for software decoding any format.

Features don't make for security holes; bad implementations make for security holes, as demonstrated there are bugs in even the simplest, most featureless formats. What you need is better testing.

Sure, every feature multiplies the number of tests, but it's possible to write those tests, if you insist on it, and it's also possible to blow off testing entirely, even if what you've written is simple and featureless, and still have exploitable security holes.

Features, complexity, are not the root cause of security flaws, failing to bring a commensurate amount of testing and rigor is the root cause. Going back to the good old days of less featureful software is not going to fix a damn thing.

HTML is already a "safe subset" of itself; HTML is merely a markup language. You don't need to implement the DOM or Javascript, especially in an email client.

The problem is, as it has always been, that there are bugs in software that renders HTML.

There have been exploitable bugs in JPEG decoders, PNG decoders, TIFF decoders, GIF decoders, even BMP decoders, BMP being the most braindead simple of image formats: would you say that we need a "safe subset" of image formats?

There have been exploitable bugs text editors. Would you say that we need a "safe subset" of plain text?

It's possible to have bugs in any language, for software decoding any format.

Features don't make for security holes; bad implementations make for security holes, as demonstrated there are bugs in even the simplest, most featureless formats. What you need is better testing.

Sure, every feature multiplies the number of tests, but it's possible to write those tests, if you insist on it, and it's also possible to blow off testing entirely, even if what you've written is simple and featureless, and still have exploitable security holes.

Features, complexity, are not the root cause of security flaws, failing to bring a commensurate amount of testing and rigor is the root cause. Going back to the good old days of less featureful software is not going to fix a damn thing.

HTML is already a "safe subset" of itself; HTML is merely a markup language. You don't need to implement the DOM or Javascript, especially in an email client.

The problem is, as it has always been, that there are bugs in software that renders HTML.

There have been exploitable bugs in JPEG decoders, PNG decoders, TIFF decoders, GIF decoders, even BMP decoders, BMP being the most braindead simple of image formats: would you say that we need a "safe subset" of image formats?

There have been exploitable bugs text editors. Would you say that we need a "safe subset" of plain text?

It's possible to have bugs in any language, for software decoding any format.

Features don't make for security holes; bad implementations make for security holes, as demonstrated there are bugs in even the simplest, most featureless formats. What you need is better testing.

Sure, every feature multiplies the number of tests, but it's possible to write those tests, if you insist on it, and it's also possible to blow off testing entirely, even if what you've written is simple and featureless, and still have exploitable security holes.

Features, complexity, are not the root cause of security flaws, failing to bring a commensurate amount of testing and rigor is the root cause. Going back to the good old days of less featureful software is not going to fix a damn thing.

HTML is already a "safe subset" of itself; HTML is merely a markup language. You don't need to implement the DOM or Javascript, especially in an email client.

The problem is, as it has always been, that there are bugs in software that renders HTML.

There have been exploitable bugs in JPEG decoders, PNG decoders, TIFF decoders, GIF decoders, even BMP decoders, BMP being the most braindead simple of image formats: would you say that we need a "safe subset" of image formats?

There have been exploitable bugs text editors. Would you say that we need a "safe subset" of plain text?

It's possible to have bugs in any language, for software decoding any format.

Features don't make for security holes; bad implementations make for security holes, as demonstrated there are bugs in even the simplest, most featureless formats. What you need is better testing.

Sure, every feature multiplies the number of tests, but it's possible to write those tests, if you insist on it, and it's also possible to blow off testing entirely, even if what you've written is simple and featureless, and still have exploitable security holes.

Features, complexity, are not the root cause of security flaws, failing to bring a commensurate amount of testing and rigor is the root cause. Going back to the good old days of less featureful software is not going to fix a damn thing.

Remote root compromise isn't serious? I have never, I mean ever, seen anyone hunker down and suck so quickly and enthusiastically as Zero__ does on Poettering, and I'm homosexual.

And yes, that is one of the four bugs listed. Any confusion in linking the bugs to the appropriate CVE is, again, entirely Poetterings fault and part of the reason he got the award.

Or a better example, let's say you have a buffer overflow in glibc's dns handling. You can update the shared library to fix the bug, most *nix systems will allow this, but the library is still loaded into every process using glibc (just about everything not statically compiled) thus every process and service is vulnerable until you restart each of them. Do you restart all services, or do you restart the machine and let startup handle it? Does your answer change if you have to do it to 100 machines with various workloads across an enterprise domain?

They probably shut down because the MITRE's CVE database is pretty much regarded as the canonical database for all vulnerabilities, open and proprietary. I've not see a security advisory that didn't have a CVE number for a long time. I don't remember ever seeing one with a reference to OSVDB.

MITRE itself has a list of things it thinks deserve CVE IDs: https://cve.mitre.org/cve/data_sources_product_coverage.html for details. Things outside of this list may not ever receive a CVE ID, even if they are valid vulnerabilities.

The takeaway is that lots of products have vulnerabilities but never receive CVEs or are included in the CVE dictionary. This is why alternates like OSVDB popped up, and why alternate vulnerability ID systems popped up recently (see DWF as a primary example).

It's a shame to lose something like OSVDB, as there really isn't a good canonical source of ALL vulnerabilities. MITRE's CVE works for vulnerabilities in big name products, but it is nowhere near inclusive of all vulnerabilities reported. Of course, OSVDB hasn't been updated recently either, so there's a big gap in even knowing what's out there. Maybe projects like DWF will help us move in that direction.

Java had its share of bugs leading to zero-day attacks - language implementation bugs, not the browser. This one made a lot of noise a couple years ago.

They are all security vulns. Read the FAQ:

http://cve.mitre.org/about/faq... First up on the FAQ
CVE is a list of information security vulnerabilities and exposures that aims to provide common names for publicly known cyber security issues. The goal of CVE is to make it easier to share data across separate vulnerability capabilities (tools, repositories, and services) with this "common enumeration."

It would make more sense, you point out a single error in my post, and it would even make more sense to write the words out for what CVE stands. I assume, you mean this: https://cve.mitre.org/

Point is, the machine has nothing to do with the problem, knowing how "the machine works" does not prevent people from crafting buffer overflows or other "vulnerabilities", perhaps knowing how languages work, would prevent a bit of "injections" ... and again: that has nothing to do with the machine.

There are several layers here that make a solution quite "interesting". On the one hand you are trying to protect your users by avoiding serving them bad content. On the other hand you want to protect your service. Protecting your users means doing more work on the uploaded content which increases your own attack surface.

Personally if we are just talking about PNGs then I think that one of the safest things for your clients/customers would be to not serve the file as uploaded, but to serve a file that is the result of a successful render->save process (which might get you a bonus improvement of allowing you to optimise the image). That way you should end up serving a valid image without any dodgy stuff someone may have tried to sneak through. Of course there have been plenty of vulnerabilities in image handling over the years. So reprocessing the images does come with it's own risk that might suggest it's own mitigations (eg doing it on a seperate untrusted server that doesn't have access to anything interesting).

There might be third party services you could use, but of course that opens up it's own questions in terms of trust, security and availability.

OTOH, OpenBSD's kernel is about 10X the size of Xen (where the BSD mantra of 'correctness' has a much tighter focus). As isolation mechanisms go, I trust Xen before any monolithic kernel. The upshot is that Xen also gives me the rich features (incl. drivers) of Linux and Windows.

Awwwww, you are so cute. You trust Xen more than kernel xyz? Really?

First of all, please read this.
Then take a look at this.

There are, let's see... right now, 35 CVEs assigned to the Xen project, in 2015 alone? 40 CVEs in 2014?

Compare and contrast with the number of CVEs published for OpenBSD. And the number of patches available for the latest version (5.8) of OpenBSD.. Here is a hint: 99% of these patches do not imply your machine is going to be ''owned'' by someone exploiting the bugs found. Yes, even the OpenSMTPD patches are pretty mild.

You can keep your Qubes OS, thank you very much, I'll stick to OpenBSD, despite all its defaults and warts.

Words of wisdom to meditate:

You've been smoking something really mind altering, and I think you should share it.

x86 virtualization is about basically placing another nearly full kernel, full of new bugs, on top of a nasty x86 architecture which barely has correct page protection. Then running your operating system on the other side of this brand new pile of shit.

You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes.

(Source.)

Say what you will of this guy, he has got a point. Virtualization is great, but not for security. Period.

The US Gov knew and published this on the 28th. Way to be 3 days late, an no doubt why /. is more than a dollar short.

https://www.us-cert.gov/ncas/current-activity

The "government" is proactive!. Cool.

Soon we'll all have flying cars for sure (or, flying SUVs with in-dash McD snack printers and heavy-duty conveyor belts in place of door-steps).

When processing an ECParameters structure OpenSSL enters an infinite loop if the curve specified is over a specially malformed binary polynomial field. This can be used to perform denial of service against any system which processes public keys, certificate requests or certificates. This includes TLS clients and TLS servers with client authentication enabled.
original advisory Hidden in plain sight. (sigh)

Isn't The Register a news satire site? [if not it needs reclassifying]

Microsoft hasn't made a JVM in - well, over a decade, at this point.

Java applets are "safe" because they're sandboxed. By default a Java application can do anything a native application can, and just blindly running a native application in the browser is clearly a horrible, horrible idea.

The majority of Java vulnerabilities are new and clever ways to escape the sandbox, thereby gaining the ability to do anything the user could do.

Of course there have been other neat vulnerabilities like CVE-2014-6601 where apparently Java's JIT can be tricked into just running native code and this can be exploited remotely. I'm unclear on the exact details of that one.

It's CVE-2015-3456. https://cve.mitre.org/cgi-bin/...

Do they? Do you have data to back this up, or are you just guessing? Because from where I'm sitting, it looks a lot like the hardest security problems are the features you expose to users.

If you don't have to have any features, then yes, you can make your software very, very secure. :-)

The CWE publishes a list of the Top 25 Most Dangerous Software Errors which aims to "list of the most widespread and critical errors that can lead to serious vulnerabilities". You'll notice CERT tags their vulnerability announcements with references to the CWE when applicable.

Most are language-independent.... no surprise to see CWE-89 (SQL injection) and CWE-78 (command line injection) in there, as well as the slough of crypto/authN/authZ-related stuff. But where are the language-dependent bugs coming from? If you drill down on the code examples for CWE-120, -131, -134, and -676, you'll see C and C++ are a re-occurring theme.

You contradict yourself at the end of the paragraph and try to come up with a reasonable substitute.

No contradictions... knowing how stuff work is a training/educational goal (for programmers and those who teach them). Not having to know how stuff works is a design goal (for language creators, API writers, and designers in general). The former gives you insight, the latter gives you leverage.

Good luck starting a security company with the slogan "We provide 90% security!"

I don't know what you're talking about. If anything, that would be "90% fewer security vulnerabilities", which sounds like perfectly good marketing.

I do use Haskell myself for certain things, and I can tell you it's no problem creating insecure applications in Haskell.

I never said Haskell was the perfect language, just that it provides good examples of achieving the needed safety properties, in that it can be extended to verify many properties that may be of interest. I didn't define "safe" in my original post, as the requried "safety" properties are domain-specific. Memory safety is the minimum needed, which would automatically handle one of the most common vulnerabilities in single programs (buffer overflows). A language that can be used to specify and check the required properties is a "safe" language for a given domain. Many languages fit most problems, few languages may be safe for all problems (although possibly undesirable for other reasons).

If all we had were Haskell's DoS vulnerabilities, we would be in a much better place.

Most exploits are due to human errors they could have done in any language

Not a chance. Here's a list of the top 25 exploits from 2011. From this list, numbers 3 and 20 would have been solved right away by using any memory safe language. Most memory safe languages also implement overflow checking, so that's 24 off too.

Languages featuring parametric polymorphism can tag unsafe values received as user inputs, so you can easily solve vulnerabilities 1, 2, 10, 14, 22, and 23 (all you really need is parametric polymorphism -- I've even done this in C#).

The crypto entries can be handled with session types that expect encrypted packets, not plaintext. Even the selection of appropriate crypto algorithm can be constrained by various parameters and checked at compile-time, ie. a Haskell type class constraint could specify a whitelist of unbroken crypto algorithms for unrestricted use, and those which are only good in restricted scenarios.

Design by contract can handle precondition violations, ie. #18, and such contracts can be statically checked these days in Haskell, C# and Ada.

A capability-secure language would handle the rest (mainly "porous defense" category remains). Few languages implement full capability security properties, and they remain vulnerable to the extent that they violate those principles.

The point is that the needed safety properties to address most common security vulnerabilities have been known for decades. Capability security was invented in the 1960s, and memory safety has been available since the first Lisp. Unfortunately, many programmers aren't interested in safety properties because they're focused too much on raw speed, but don't want to spend the verification effort to use that speed safely (Frama-C or Ada), or they want to avoid all verification effort period (dynamically typed languages).

The linked patch only fixes the primary vulnerability. There is an additional trailing string processing vulnerability (CVE-2014-7169) that is fixed by using the patch posted here.

In the context about dhcp, there was a very similar problem before and people added some sanitation:

http://cve.mitre.org/cgi-bin/c...

So yes, people are aware that having an attacker control parts of the environment is a bad idea and this needs to be restriced. But for some reason this fix to dhcp does not cover all possibilties..

"Click on the update and you should see a 'More Information' link on the right. Click it and your browser should open to a MS knowledge base page that explains what the patch does".

"To view this vulnerability as a standard entry in the Common Vulnerabilities and Exposures list, see CVE-2014-0318." ref

'win32k.sys .. does not properly control access to thread-owned objects, which allows local users to gain privileges via a crafted application, aka "Win32k Elevation of Privilege Vulnerability ."'

Windows doesn't do font processing in the kernel

then where did this come from?

You simply don't know the future security bugs that will affect your infrastructure. Just look at http://www.cve.mitre.org/ or any distribution security announcement like https://www.debian.org/securit... . Security bugs are discovered all the time. With this fact in mind you realize that you need more than a single protection layer to get a chance to detect and drop a harmful traffic. The bug could be deep into the kernel, making almost any magic possible from the application point of view. Having only a few ports open is not enough to protect against this, as the kernel structure and notion of port could be corrupted.

Did _you_ know that your wireless router was using OpenSSL to manage EAP? Or did you just assume that having SSH blocked and not serving HTTPS would be enough?

And even if you did, is it even possible for you to upgrade a single library on your access point?

Try going back to the original CVE, the plethora of vulnerability checkers, or any of the press surrounding it. Every reference to Heartbleed pointed to HTTPS or, rarely, TLS and VPN services as being vulnerable to the bug. Now pretend that you don't know the implementation details of WPA and EAP. Based on all of that, why would you even consider updating or replacing every wireless device you have which don't use HTTPS unless the manufacturer told you?

Moreover, when have manufacturers of popular wireless equipment _ever_ produced timely and relevant updates without at least eight months lead time and court cases in at least three countries?

> I'm not familiar with how CVE internals work

Why are you even arguing here, then?

CVE IDs are assigned by a number of CVE numbering authorities. This includes Mitre itself plus big software companies like MS and Red Hat, plus few extras. Each authority requests pools of CVE IDs to assign from Mitre. Year in CVE ID is the year of original bug report, which blows up the "sat on it for 6 months" theory.

Here's that initial bug report referenced in CVE. Note how it says: "Date: Mon, 5 May 2014 12:08:11 +0200 [snipped message to oss-security list] CVE-2014-0196 has been assigned to this issue. [snipped] Date: Tue, 29 Apr 2014 12:38:36 -0400 [snipped original bug report and patch] We, at suse, would appreciate embargo till Mon May 5th."

That is, discovered and reported with a patch at 140429, then published at 140505 with an ID from SUSE's pool reserved at 131203.

HTH, HAND.

PS: Hearbleed is also from 131203 IDs batch, as well as at least 323 others this year.

> I'm not familiar with how CVE internals work

Why are you even arguing here, then?

CVE IDs are assigned by a number of CVE numbering authorities. This includes Mitre itself plus big software companies like MS and Red Hat, plus few extras. Each authority requests pools of CVE IDs to assign from Mitre. Year in CVE ID is the year of original bug report, which blows up the "sat on it for 6 months" theory.

Here's that initial bug report referenced in CVE. Note how it says: "Date: Mon, 5 May 2014 12:08:11 +0200 [snipped message to oss-security list] CVE-2014-0196 has been assigned to this issue. [snipped] Date: Tue, 29 Apr 2014 12:38:36 -0400 [snipped original bug report and patch] We, at suse, would appreciate embargo till Mon May 5th."

That is, discovered and reported with a patch at 140429, then published at 140505 with an ID from SUSE's pool reserved at 131203.

HTH, HAND.

PS: Hearbleed is also from 131203 IDs batch, as well as at least 323 others this year.

There's no such thing as "GIT report" mentioned anywhere here, only GIT commits and they're too recent...

Did you mean CVE? CVEs reservation dates don't correspond with bug discovery date - for example, CVE numbered one less than this one is not even created yet, but it lists the same "20131203" reservation date.

I guarantee you're not far, far smarter than us.

That really doesn't have to do much with "smart". Security for such things is mostly about checklists, knowing them and knowing which apply. A good start is CWE/SANS Top 25 Most Dangerous Software Errors and of course the OWASP Top 10.

They do that by design. Referer is part of the spec. URLs -- or GET requests in general -- should not contain any private data. It's even CWE-598.

More specifically related to SSL:
http://cve.mitre.org/cgi-bin/c...
http://cve.mitre.org/cgi-bin/c...

So if you really dig deep, you can find two SSL vulnerabilities from IIS which date back to over 10 years? That sounds like IIS is doing just fine in that department.

More specifically related to SSL:
http://cve.mitre.org/cgi-bin/c...
http://cve.mitre.org/cgi-bin/c...

So if you really dig deep, you can find two SSL vulnerabilities from IIS which date back to over 10 years? That sounds like IIS is doing just fine in that department.

Ignorance is bliss.

http://cve.mitre.org/cgi-bin/c...

More specifically related to SSL:
http://cve.mitre.org/cgi-bin/c...
http://cve.mitre.org/cgi-bin/c...

Ignorance is bliss.

http://cve.mitre.org/cgi-bin/c...

More specifically related to SSL:
http://cve.mitre.org/cgi-bin/c...
http://cve.mitre.org/cgi-bin/c...

Ignorance is bliss.

http://cve.mitre.org/cgi-bin/c...

More specifically related to SSL:
http://cve.mitre.org/cgi-bin/c...
http://cve.mitre.org/cgi-bin/c...

are you sure about that?

unsafe
{
// srcPtr and destPtr are IntPtr's pointing to valid memory locations
// size is the number of long (normally 4 bytes) to copy
    long* src = (long*)srcPtr;
    long* dest = (long*)destPtr;
    for (int i = 0; i < size / sizeof(long); i++)
    {
        dest[i] = src[i];
    }
}

that's valid C#, all you need to do is inject something like that into the codebase and let the JIT compile it (using all the lovely features they added to support dynamic code) and you're good to get all the memory you like.

Now I know the CLR will not let you do this so easily, but there's always a security vulnerability lying around waiting to be discovered that will, or an unpatched system that already has such a bug found in any of the .NET framework, for example this one that exploits... a "buffer allocation vulnerability", and is present in Silverlight.

The moral is ... don't think C programs are somehow insecure and managed languages are perfectly safe.

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.

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.

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.

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.