Google discloses three severe vulnerabilities in Apple OS X
cnet.com
cnet.com
A zero-day is, by definition, an exploit that the vendor has had zero days to react to. It's not just an unpatched vulnerability with a proof of concept exploit available for it.
Apple has been aware of these issues since October.
> A zero-day (or zero-hour or day zero) attack or threat is an attack that exploits a previously unknown vulnerability in a computer application or operating system, one that developers have not had time to address and patch. It is called a "zero-day" because the programmer has had zero days to fix the flaw (in other words, a patch is not available)
He asked "Do you have a source for that definition?" and you said you didn't have a source as reliable as Wikipedia, then attacked the reliability of wikipedia, which leaves your source in doubt. So what IS you source?
That's what he asked in the first place, and now that you're hopefully done casting doubt upon his source, you still haven't answered what your source is yet, except to say that it's less reliable than "a horrible source to trust for anything debatable". So please give us a link to your source, so we can see it ourselves.
I'm not sure that's a helpful definition. It's pedantic to the point of no longer applying to any real-world situation and thus sort of pointless.
0-day basically means the that the vendor learned about the vulnerability the same day everyone else did, it should not be used in situation when vendor was notified promptly, yet still ignored it and didn't fixed it. I don't understand so many people have problem with this.
I'm probably not the programmer responsible for fixing a bug in my OS; hardly any of us are. But we're all at the mercy of that bug being fixed. So aside from PR, there's literally no reason why I should care how long the vendor has known about it. I care how long everyone else has known about it prior to a fix being available.
If there's going to a be a widely-used term for one or the other, language is going to evolve such that the term covers the latter case because we have practically no reason to care about or refer to the former.
I would also argue that you should choose a word to describe such serious flaws in such a way that the "flaw" doesn't appear to go away if nothing changes except the passage of a very small amount of time. I don't want vendors saying, "we have no zero-day exploits" simply because they waited 10 hours to make the statement.
Personally, I've noticed more use of "zero-day" to mean "exploits are now public but no patch is yet available" than to mean literally "programmers just learned of the bug today".
The problem with what you're trying to put forward here is that you think this is an interpretation. It's not. A 0-day has a very strict definition.
You can't just choose random words or expressions you don't understand without looking them up and decide they mean something else because you thought they did. Otherwise, the annals of medicine would look very different.
"An attack on a software flaw that occurs before the software's developers have had time to develop a patch for the flaw is often known as a zero-day exploit."
http://www.tomsguide.com/us/zero-day-exploit-definition,news...
The meaning of a word or term today may not be the same tomorrow, languages evolve with the way people communicate, not with the way they get defined.
0-day is a good example, because people outside the security field only care about whether they're vulnerable or not, not about the intricacies of the term.
Because bugs can't be fixed in zero time, and most readers are interested in the practical matter of whether there is a window of unpatched widespread vulnerability, this public-disclosure-focused definition may in fact be more useful.
We already have a term for that, though: "unpatched vulnerabilities". Using the term "zero-day" erroneously communicates to the reader that Google surprised Apple et al with this thing out of the blue, and just handed crackers the tools to start exploiting it without giving Apple time to develop countermeasures.
What's special about today, with an exploit being widely-known but no patch available? That's the new situation people are grasping for a term to describe.
'Zero-day' somewhat fits, at least from the perspective of everyone outside Apple: OSX users and those potentially attacking them. It's a brand-new green-field risk/attack for them!
It's also somewhat problematic, for the reasons you list and others. There may be a better term yet to be discovered, that maintains the special distinction for vulnerabilities that the vendor only learns about simultaneous with exploit-availability. But still a lot of people use and understand the term to apply to the window-of-danger from unpatched "Project Zero" 90-day reveals.
Using 0 day to refer to "days since disclosure to vendor", well, it becomes a 1-day on the very next day. Which means you can only use the term on one day out of all time.
If we used 0 day to refer to "days since release", as in "iOS 8 was released today and there's already an exploit" then that would be meaningful.
And which derives from its original usage in the late 1990s warez scene. A 0-day licensing crack was one available on the same day a new product hit the market. Many reputations were built on achieving this.
Leave aside memory safety, input validation, actually caring about the quality of your work, whatever. mmap_min_addr stopped a ton of attacks back in like 2007-10 when Linux had a local privilege escalation-of-the-month (and RHEL, which hadn't enabled it yet for backwards-compatibility concerns, got hit more frequently). It's not a particularly aesthetically-pleasing solution, but it's an effective one.
Are there legacy apps on OS X that require mapping the zero page? Executable? That Apple cares about supporting?
I've run into two things on Linux that need to map the zero page: versions of MIT Scheme from before 2009 (because the compiler was doing something super weird), and Wine, when running certain DOS / Windows 3.1 apps. Anything of that era probably stopped working on OS X when they killed Classic. Even Carbon has been dead for three years.
With regard to only this point, probably half if not more of the the top 15 grossing games on the Mac AppStore Games page today are either Carbon Apps or at minimum require the Carbon framework.
On Yosemite, 64-bit binaries aren't allowed to do this.
Although every time I go "I didn't realize X on Y worked", it seems like games are the rationale, and not very surprisingly, since they exercise a relatively small part of the API surface apart from OpenGL. (Mono, some HTML 5 things as mobile apps, and Humble Bundle's asm.js collection all come to mind.)
Can OS X take a cue from iOS and require a special Apple-signed entitlement to do this (unless root overrides it in a config file), or is it not worth the trouble?
Also, does Wine actually require this in general? My understanding was that Wine needed this for legacy Windows apps that themselves map the zero page, but recent-ish apps designed for XP or later shouldn't do that, right?
CodeWeaver's Crossover is quite good as well. It can play Skyrim on my 2012 MPB with decent quality. I mostly use it for older games though - rollercoaster tycoon and the like.
That was a kernel null dereference, it really has nothing to do with creating a mach-o that puts code in the first page and there are valid reasons to do it, SheepShaver and BasilliskII come to mind.
//map NULL page
vm_deallocate(mach_task_self(), 0x0, 0x1000);
addr = 0;
vm_allocate(mach_task_self(), &addr, 0x1000, 0);
char* np = 0;
for (int i = 0; i < 0x1000; i++){
np[i] = 'A';
}
Re SheepShaver and Basilisk II, those are non-Mac apps, and at least on Linux, there's no requirement for an emulator (like qemu) to map address zero in the host to offer a usable zero page in the guest; it's a convenience depending on how you write the emulator, but it's by no means needed. I don't think this is true of other host platforms either, but I'm less familiar with those.
Because they're monolithic, bloated, and written in C.
(Rust guys, please don't screw up. We need a win there.)
While it's true that Rust would help here, it is very unlikely that a Rust kernel project would get as far as e.g. Linux and let alone replace it.
Of course, rewriting and existing kernel stepwise would be interesting, if possible.
Perhaps it's possible to write a new kernel in Rust, and have it be backwards compatible with Linux, by "wrapping" the Linux kernel and drivers in sandboxes?
So a Rust kernel with some kind of built-in environment isolation, in which it can run the real Linux kernel. The running Linux kernel would then access physical hardware through a wrapper in the Rust kernel, while the Rust kernel would access hardware directly.
That's really the only way I see this project gaining widespread adoption: by leveraging Linux. Linux simply has too much momentum to be replaced with something non-compatible.
Of course, a Rust kernel could be useful for all kinds of things other than replacing Linux. Like a Mirage OS-type kernel that uses Rust to write drivers in Rust (instead of OCaml).
Linux as a UNIX clone, will never use anything else other than C.
Replacing C in MirageOS sounds more likely.
for an overview of what's going on in this area. If you're running containers on a hypervisor, with files on storage servers elsewhere, most of the Linux kernel is dead weight. Most of the kernel can be replaced by a modest glue library. Here's one, written in OCaml: http://anil.recoil.org/papers/2013-asplos-mirage.pdf
As containers catch on, we'll see more systems specialized to run nothing but containers. They will be much simpler than Linux or Windows. System administration will be external, as it is for cloud systems like Amazon AWS now.
I'm not convinced that Linux is unkillable, though. This thread is about OS X, I'm typing this on an OS X machine, etc. I suspect that if you do a good job of working with people's hardware (Apple has an advantage, of course), you can run Chrome, and you can run anything that's portable between OS X and Linux, you can get pretty far.
My list goes as:
- kernel memory and userspace memory is hardware separated as it was originally with some early architectures
More about it here: http://phrack.org/issues/64/6.html#article
- microkernels
Having a formally verified ring0 execution block and everything else is running in a less privileged space, this would allow kernels to protect themselves against bad drivers and other parts of the operating system that can be used as attack surface today
- safe userland
this is I guess where Rust could help the most, having a memory safe low level language
UNIX is married with C, so any attempt to replace C, means breaking with the UNIX mindset, which has proven very hard to do.
Even successful research projects like Oberon, failed to cater the industry, and this was before UNIX became widespread.
Regarding microkernels, most of the embedded space OS are actually using microkernels.
I am following MirageOS, HaLVM and Microsoft's Ironclad as possible safer OS.
This is why also also like what Apple, Google and Microsoft do on their mobile OS to reduce the amount of allowed unsafe code. Even though it isn't at kernel level.
I don't believe this is particularly true, although I haven't explored it very far. UNIX is married with the API/ABI exposed by the so-called "C" library. So far, there have been no languages that offer native interoperability with C and have gained significant popularity, other than C++, and C++ is certainly pretty popular on UNIX (Qt, gcc, etc.). Rust does offer that and is (evidently) picking up a ton of steam, and you can get to the point where stupid tricks that previously required a C derivative can be done in Rust.
http://mainisusuallyafunction.blogspot.com/2015/01/151-byte-...
In fairness, this often also requires things like "C" strings, the "C" locale, etc. But those things can either be done smoothly enough from Rust, or are wrong anyway, that I think there's a chance to break the C stranglehold here.
UNIX and C were developed together. Like most system programming languages before it, and even those that failed in the market, C's original purpose was to bring its host OS to life.
So to remove C from a UNIX compatible OS, you need to remove C from UNIX culture, which is impossible.
The resulting OS wouldn't be UNIX any longer, it would be Plan9, Inferno, something else.
As for C++, is pretty popular nowadays because it also came from AT&T, so it has been part of the UNIX culture from the mid-80's. But never at kernel level.
There are OS written in C++, like Symbian, BeOS, IBM i and others. None of them are UNIX compatible OSs.
I cannot imagine any commercial UNIX vendor to allow anything else other than C on their kernels, nor I do see it happen in the FOSS world.
Alternative OS that try to research new paths in OS architectures, yes. But not OS that try to clone UNIX culture.
If you look at my comment history, I am not very found of C, but I just don't see it happen from the social point of view of how comunities behave.
(And I'm personally not a fan of UNIX culture, at least in 2015, partly _because_ it's a culture that thinks C is a defensible language to program in, at least in 2015.)
> And I'm personally not a fan of UNIX culture
Personally, I have learn a lot from UNIX and it allowed me quite a few interesting job opportunities in my career.
But I was also part of Amiga, BeOS, Windows, Demoscene, Oberon cultures, so in the end I enjoy systems that try new paths.
And even though I don't agree with Rob Pike ideas for Go, I surely agree with his opinion about UNIX.
Yes, microkernels and hybrid kernels too. Yet Linux/FreeBSD/Random Unix Clone are monolithic.
It is the time for a new safer kernel! :)
None of the systems you're suggesting have formal proofs of correctness, and this one not only has such proofs, but is written in C.
And it's the sort of thing that you can turn on in an existing kernel. Rewriting the whole kernel in Rust is a major (but worthwhile) project; adding this restriction is, in its simplest form, just adding `if (addr < 4096) return -EFAULT` to the page-allocation routine. As another commenter pointed out, OS X does have this restriction for 64-bit binaries now.
That was a mixed bag - with support on both sides of the aisles, some decrying Patch Tuesday, some in support.
What will happen here? Will Google be lauded for consistency, or castigated for not "working more closely" with Apple (for varying definitions of "working closely", up to and including potentially delaying disclosure around arbitrary timelines)?
Both were published days before update schedule.
http://www.imore.com/latest-os-x-10102-beta-kills-google-dis...
I understand the benefit of this program to the public, but what real benefit does funding Project Zero Day provide Google?
Edit: for the apparent doubter of this, see any number of articles about Google's 40,000 macs that they use as dev machines, for example: https://www.usenix.org/conference/lisa13/managing-macs-googl... http://www.theregister.co.uk/2013/11/27/google_mac_support/
Source: worked there once
(I'm a Googler)
A common monetization method used by malware distributors is to secretly replace legitimate ads that get loaded on the machine (such as Google's) with their own.
Doing this on every single web page visited by that machine for the rest of its existence, and multiplying that by hundreds of thousands of other infected machines out there, and multiplying THAT by the dozens of different black hat groups doing this simultaneously, it adds up to a lot of lost money for Google.
To me it feels like they're throwing their competitors under the bus in this way as opposed to running slander campaigns or witty commercials like Samsung, Microsoft, and Apple do. I'm not saying this is their intention but that is the way it comes off and it cannot be good for their reputation.
A non-profit organization funded by the entire tech industry would have more credibility.
They do offer a bug bounty for their own products, to encourage third parties to do to them exactly what they're doing to Apple and Microsoft.
Of course, it's an uphill battle with the manufacturers/carriers. But as long as Google is not applying fixes to Jelly Bean, the manufacturers can always blame Google.
[1] http://www.androidpolice.com/2015/01/23/google-issues-offici...
[2] https://developer.android.com/about/dashboards/index.html
Not everything has to be directly linked to selling ads, Google is a group of people. Some companies plant trees, Google has this, I guess.
1. Google uses Mac OS and Windows internally, they're a big enough company that even untargeted malware that hits a small percentage of systems costs them money (not to mention targeted malware), and they're also a big enough company that the amortized cost of Project Zero, across all employees, is affordable.
2. The top-notch researchers who find vulnerabilities in their server stack (Linux, etc.) also like looking at different OSes occasionally, and this is a way of recruiting and keeping them at Google, which leads to them disclosing and fixing Linux security issues internally while waiting on an external response.
3. They're unhappy with their software vendors not taking security and vulnerability response seriously, and they're trying to shift the popular consensus / Overton window on how seriously people should care and what the industry-standard response to reports should be.
http://www.imore.com/latest-os-x-10102-beta-kills-google-dis...
I feel like somebody is trying to execute some kind of buffer overflow attack against my brain.
Consider what a 1day is. A "1day" bug is one that looses value because it is likely that some systems have now been patched such that you as an attacker are not guaranteed that every system you touch with your exploit will fall. A 365day is likely useless, depending on the target platform. Hence, the entirety of its meaning has to do with risk, not procedure or ethics.
It is fine if you read Wikipedia's definition and decide the meaning is otherwise. After all, language changes. But if anyone in the future wants to understand the etymology of the meaning behind "0day" they should consider that the meaning appears to have changed (in the minds of many that actually don't even work in the field of reverse engineering).
"We're not placing any particular bounds on this project and will work to improve the security of any software depended upon by large numbers of people, paying careful attention to the techniques, targets and motivations of attackers."
http://googleonlinesecurity.blogspot.com/2014/07/announcing-...
They haven't published Cisco bugs, but they do have a pretty broad scope.