This would have close to zero latency, and would eat precisely zero processor time when idle.
Still bad. You are tying up precious resources such as processes, threads and memory. In general it is better to:
1. Register for events, e.g by filling a jump table and register it with the OS. Each item in the jump table represents a well-known function such as "device arrived", "system goes to battery power", "device removed" or "system shutting down".
2. return and relinquish any resources such as process, threads, memory, handles.
3. When a routine is invoked by the OS then perform the function as quick as possible and return. Don't tie up resources.
But on the flip, Microsoft's hardware abstraction layer is a terrible, horrible, implimentation that makes every access from userspace terribly expensive.
And worse? Some of the documentation specifically says they want it that way! On purpose!
Citation needed.
Windows actually has a rather sophisticated driver model which allows many drivers to be implemented in user mode or at least be divided so that big parts can run in user mode. This improves both stability and security. A relevant type of drivers in this context is bus drivers, specifically bus drivers for USB. These drivers will discover new devices on the USB bus *regardless* of their make, capability etc. The bus driver til inform *your* driver when a device arrives. No need to scan or poll for devices. If you do it right you can just sit there and wait to be informed. No need to poll, no need to even tie up a thread in waiting state.
Everytime I have to work with HAL I'm filled with a strong urge to strip all my clothes off, burn them, then take a cold shower while shivering up in the corner, scrubbing my skin raw, chanting "must...wash...away...the sin..."
It knocks both DRM and Windows in one sentence. Which is popular on slashdot.
Facts don't matter, accuracy doesn't matter. Comments can be outright lies (like this one) and still achieve the highest ranking as *informative* just because it plays to a popular myth.
No, games are *not* run with admin rights. No they do *not* need to run with admin privileges, not even to use DRM. Especially not the online DRM variety that steam uses.
So the minimum requirement is that you can delete all the keys.
Wrong. There is no requirement that you *explicitly* can enter UEFI Setup Mode. The system vendor MAY allow such an explicit option, but the MINIMUM requirement is that he MUST allow Setup Mode to be entered by deleting all keys.
Read what you quoted again, please: 1) It SHALL be possible for a physically present user to use the Custom Mode firmware setup option to modify the contents of the Secure Boot signature databases and the PK. 2) This MAY be implemented by simply providing the option to clear all Secure Boot databases (PK, KEK, db, dbx), WHICH puts the system into setup mode.
So the owner of the system can ALWAYS enter setup mode. He may have some direct way to do that, but he can ALWAYS delete the key databases, which will cause the system to go into UEFI Setup Mode.
"If the user ends up deleting the PK then, upon exiting the Custom Mode firmware setup, the system is operating in Setup Mode with SecureBoot turned off."
So when you delete the keys, SecureBoot is turned off.
Correction: When you delete the keys the system enters Setup Mode. If you choose to exit the automatically invoked setup mode WITHOUT entering a new platform key, THEN secure boot is turned off. Which makes perfect sense as there are now no keys in the firmware which could validate anything.
There's also an option to always put the Microsoft key back in place. But that's it.
No, you can enter ANY key into the Platform Key database. From http://lwn.net/Articles/447381/ : "Before a PK is loaded into the firmware, UEFI is considered to be in "setup" mode, which allows anyone to write a PK to the firmware. Writing the PK switches the firmware into "user" mode. Once in user mode, PKs and KEKs can only be written if they are signed using the private portion of the PK, though KEKs can be freely written during setup mode. Essentially, the PK is meant to authenticate the platform "owner", while the KEKs are used to authenticate other components, like operating systems."
At no point does it guarantee that you can enter an arbitrary key and keep secure mode on.
And you are wrong. The PK (Platform Key) is the "owner" key. You can enter your own key if you like.
Which is basically what I said.
But you were mistaken.
And "possible" can be provided by means of, say, a supplied disk available at extra cost from the manufacturer that has to be inserted for such action to be taken at all.
Lip service.
So, basically you are spreading FUD: *Fear* that it may incur extra costs, *uncertainty* because you choose to disregard facts and present your own speculation and conjecture as facts, and finally *doubt* as to the "real" intentions behind secure boot.
I thought the "embedded" Flash of IE is similar to Chrome's embedded Flash. Meaning Microsoft maintains its own build of Flash like Google maintains its own Flash. So it's up to Microsoft to fix any security issues and not rely on Adobe to release a patch to the consumer. So it could be a good thing like Chrome or a terrible thing like IE6.
They are similar. It is still Adobe developing Flash, but they coordinate releases with both Google (for Chrome) and Microsoft (for IE) so that vulnerabilities are not implicitly revealed through one version where an attacker could version compare and reverse engineer to figure out the vulnerability.
Both browsers sandbox the Flash plugin. In the case of IE the Flash process runs under low integrity mode (protected mode).
On top of that, the "embedded" Flash is only available to a Microsoft-controlled white-list of sites. An attacker cannot simply set up a fake site with Flash attack code. IE will refuse launch the embedded Flash for all but the white-listed sites.
On Windows 8 the "embedded" Flash is only available in the Metro^h^h^h^h^hModern version of IE. The desktop version still require explicit installation of Flash if you want to use it. This latter is the situation with IE10 on Windows 7 as well.
Apple still maintains their own Java 6 until EOLed
FYI, Java 6 EOLed now, Feb. 2013, no longer supported by Apple
For your information: http://support.apple.com/kb/HT5666:"Multiple vulnerabilities existed in Java 1.6.0_37, the most serious of which may allow an untrusted Java applet to execute arbitrary code outside the Java sandbox. Visiting a web page containing a maliciously crafted untrusted Java applet may lead to arbitrary code execution with the privileges of the current user. These issues were addressed by updating to Java version 1.6.0_41. For Mac OS X v10.6 systems, these issues were addressed in Java for Mac OS X v10.6 Update 13"
Apple patched this vulnerability on feb 19th 2013. After systems had been compromised. Macs which had been upgraded from previous versions where Java was installed *still* has Java installed. Apple obviously felt obliged (as in "egg on their heads obliged") to patch this one. OS X systems all over the world have been compromised because of Apples approach to security, especially Java security.
This payload was Mac specific, and Mac computers were the only one affected.
Well, that's not what TFA says, nor any article I've read about it... but what possible reason would you have for making shit up?
It wasn't just the Macs. This was an attack on the Oracle java browser plugin, not an attack on a specific platform.
Troll less, recoiledsnake.kthxbai.
Yes, it was just the macs. The attack vector was a Java vulnerability, but the payload is always OS specific. Some attacks have been known to serve different payload after sensing the OS. But not this one. This payload was Mac specific, and Mac computers were the only one affected.
Coincidentally, the Java vulnerability exploited in the attack had been patched by Oracle several weeks before. But the vulnerability was still in the Apple maintained Java 6 (Apple still maintains their own Java 6 until EOLed - Oracle has only committed to maintain Java 7 on OS X).
Use dism.exe. It will let you capture freshly installed machine - even with installed applications - back into an install image, i.e. slipstreaming. From the install image it will work exectly like the original image, only it will have all of the installed service packs, updates and patches already installed.
Microsofts activation technology relies on local hashcodes generated from fingerprinting properties of devices. It allows for a certain amount of changes over time, e.g. changing disk. It contacts the activation servers during activation, but after that it *never* phones home.
It would be better if it was totally free of this DRM restricting users. I believe that it is a fair expectation by the customer expects that he *bought* the product. Most regular customers do not get the difference between a license to use (and in this case restricted to a single device) and a product be owns.
Microsoft surely knows that Secure Boot won't affect savvy nerds from converting to Linux. They also surely know that Linux is still growing organically, relying on word-of-mouth and firsthand try-before-you-buy experience.
You are seriously delusional. "Converting" to Linux is not, has never been and will never become a threat to Microsoft. Right now Microsoft is pressured on other fronts, such as desktop PC losing relevance, not being on the boat on mobile and not competing effectively in the tablet game.
You are trying to wage last decades battle. Microsoft does not feel threatened by Linux on the desktop *at* *all*. Get real. The threats to Microsoft do not come from conversions in the x86 space, the come from vertical players and mobile, like Chromebooks, tablets, smartphones.
Note how *all* of these emerging platforms have more restricted app models, and especially *boot* models. Microsoft is simply evolving their primary platform to match the features and security (from closed and semi-closed gardens) of the threatening platforms.
The threat to Microsofts desktop business is *not* Linux. Even though Linux has evolved in that space and on the surface appears to be able to go head-to-head, Microsoft Windows is still *much* more mature than any desktop Linux. Consider for instance group policies, restart manager, volume shadow service, various troubleshooting guides, shims for both application and device compatibility etc. The real threat is that the desktop become irrelevant.
If the desktop is perceived as less secure than an online counterpart, Microsoft will be losing. They *need* to ensure secure boot. It is not a anti-Linux move at all. You are flattering yourself. And being stupid.
Flash in Firefox is only sandboxed like Chrome on Windows:
... offers several new features aimed to make the widely used browser plugin more secure — including a new security “sandbox” for Firefox on Windows.
But not on OS X. Chrome on Windows uses UAC/MIC too (and also puts in place some extra sandboxing features). Note, Firefox itself on Windows is still not sandboxed. This sandboxing only applies to the Flash plugin, not the browser itself and not to other plugins. An exploit running on Windows is running under low-integrity mode. It can not write anywhere to infect the system.
Firefox on OS X is not sandboxed; not the browser itself, not plugins in general and not Flash by itself. An exploit runs as the current user once it is running shell code. It runs with the user privileges and can write anywhere the user can, i.e. it can infect the local user account.
Does this bug also affect users of those OS's, because last time I heard a) Adobe isn't offering a flash package for current android b) Adobe isn't offering updates to the Linux flash version.
I'll assume that Linux users can have the vulnerable version, is there something in the OS that makes them immune or were they just not mentioned?
The 1st paragraph of TFA:
Adobe has released security updates for Adobe Flash Player 11.5.502.146 and earlier versions for Windows and Macintosh, Adobe Flash Player 11.2.202.261 and earlier versions for Linux, Adobe Flash Player 11.1.115.36 and earlier versions for Android 4.x, and Adobe Flash Player 11.1.111.31 and earlier versions for Android 3.x and 2.x. These updates address vulnerabilities that could cause a crash and potentially allow an attacker to take control of the affected system.
Short of using SELinux or apparmor on Linux (and live with the consequences), there is nothing to prevent an exploit using these vulnerabilities through e.g. Firefox or other non-sandbozed browsers. IIRC Chromium uses a sandbox which would prevent the attack from infecting your account.
Windows uses low-integrity mode to sandbox Flash in browsers which is why the attackers try to use an alternate (and lower yeilding) attack vector through older versions of Microsoft Word (Word 2010 sandboxes the entire document including any Flash content if the document was downloaded from an untrusted source or received through an email)
Wrong. I am the supplier of the inputs for the product that is being packaged by Google and sold to advertisers, and Gmail is (one of many parts of) the payment Google provides to me in return for providing those inputs.
The "input" you supply is your privacy. You sell your (and your contacts) privacy to google for access to their services. That's the transaction. When somebody sends you an email, Google scans it to learn things about you and your contact who sent it.
If the email mentions a particular brand of shoes, Google may start advertising those to you when the contacts birthday approaches. They may also use the information sent to you in confidence to target advertising to your contact.
You are selling your privacy, and your contacts privacy. For access to "free" services.
We see here how the Windows platform has been battle hardened to the point where the attackers have to resort to lower-yield secondary attacks. Head-on attacking Flash on Windows does not get the attacker very far because of the security advancements such as Mandatory Integrity Control (MIC). That's why the attackers try to exploit it in contexts where MIC does not prevent system infection, such as through older versions of Microsoft Word through emails.
OS X is still wide open to such head-on attacks when a vulnerability exists, especially Firefox because Mozilla has steadfastly refused to put in place a proper sandboxing barrier. Even Safari has some sandboxing in the latest version of OS X.
Firefox not. A vulnerability in Firefox or one of its plugins means significant risk of successful exploits.
Flash on Windows executes in a low-integrity process. Even if a Flash vulnerability is exploitable and shellcode gets to execute in the Flash host process, it still cannot write anywhere or interact with higher integrity objects because of mandatory integrity control (MIC) which was introduced with Vista.
The upshot: Attackers have to try secondary routes on Windows where the conversion rates are much, much lower. And this specific attack vector will not work on Word (or other Office applications) since Word 2010. Since the 2010 versions, internet downloaded documents are also opened in low-integrity mode, meaning that even here the shellcode would be similarly restricted.
Windows users are targeted with Microsoft Word documents delivered as an email attachments which contain malicious Flash content
Why?
Probably because of Windows sandboxing Flash through low-integrity mode. Even if you get to exploit a Flash vulnerability and execute your shell code on Windows, the code is still severely restricted in what it can do. Code executing inside of a low-integrity process can still not infect a system as write-ups (writing or interacting with a higher integrity object/process) are denied.
They could as easily infect you with a macro. Who in their right mind opens a Word doc from and unknown source, especially when Windows warns you when you start to open a word doc in Outlook (we use Outlook at work).
No, infecting with a Macro is more difficult since the last several versions of Word. Word will not automatically run macros and also has an internet-origin policy whereby documents received through Outlook or other email clients or downloaded using a browser is tainted with the "internet zone". You have to dismiss several warnings to run macros from such a document. But if Word will run Flash content (show the animation) and a vulnerability can be exploited, shell code can run as a user.
That is, until Word 2010 which *also* runs in low-integrity when viewing content tainted with the internet zone. Since Word 2010 the shell code will still be confined to the low-integrity sandbox.
You'll find hundreds and hundreds of security patches with more being released every Tuesday. If you really want to see a leaky sieve of an OS look no farther than Windows.
Patch tuesday is not "every tuesday". It's the second tuesday of every month, i.e. 12 tuesdays per year as opposed to 52 as you claim.
Patches are not just security patches, they also include stability patches, compatibility patches, language updates and more.
Comparing Java to a full operating system is a little disingenuous too.
If you must compare to something then you should compare Java to.NET Framework. But I wouldn't recommend you doing that if you like Java.
Java has consistently many times more security problems than.NET Framework, even if you compare just JRE with the *full*.NET framework (which include enterprise features comparable to what you get with *both* JSE + JEE).
I think the best thing about a decentralized model is the guys who run release engineering can run their own clone and pull when it suits them. And developers can work on branches, merge locally and test everything correctly to their own satisfaction before pushing. When everything is centralized it is not uncommon to see some email telling people a particular branch is locked for a merge, or for a build and it can go on for hours or days.
But in TFS you can automate all that. TFS can build by label, by changeset or simply by point-in-time. Developers can pull specific versions out locally, also without branching. Only incompetent build engineers would ask developers to refrain from checking in. Really. Even as a developer I can request such a build.
Sounds like they are going to use it internally. That still doesn't mean that you will be able to report bugs to MS developers.
Not likely. They already have TFS (or rather TFVS) which is pretty powerful. TFS is centralized and not based on a distributed model like Git. But each model has core advantages over the other.
Being centralized it is easier to create overview and centralize building, integrate with project management, testing, bug reporting etc. with TFS. But TFS is also focused on creating a single product and doesn't lend itself as easily to forking projects like Git does. TFS does branching and merging very, very well, but the central repository has to know about the branches, i.e. it is not so easy to create local ad-hoc branches.
Git is based on a decentralized model which is very, very good when you have a fluent number of products branching off from a repository. Git doesn't automatically expect a branch to be merged at some point, indeed the repository does not *know* about branches, it only knows about change/patch sets. However, the distributed model also means that there is no one central repository and you cannot use the repository to track *ongoing* work (who's working on what).
In some cases Git is better. In other cases the TFS model is better. If you have a distributed development model go with Git. If you have a very centralized development model go with TFVS.
They did the smartest thing they could have done, which was to put an Apple-style interface on a free, high quality implementation of an operating system that was more than powerful enough to hang with the industry leaders, well understood by geeks, and which contained, essentially, the reference implementation of the protocols that the internet runs on.
Were you around in 2001? I don't think "high quality" is a term anyone would use to describe those first versions of OS X. It was slow, user interface sluggish, riddled with kernel panics. Apple actually had to offer a free upgrade to 10.1 - which was still slow and sluggish but somewhat more stable. OS X eventually grew into a high quality OS, but those first versions were certainly not. Until Tiger it was kind of a joke, really.
"They suspected that the attackers somehow compromised the system of one of the users and used his access to the systems."
I heard something about the lazy idiot between the screen and the chair. Secure boot doesn't and can't fix stupid.
So when a system is compromised for most of a month, potentially putting users who download binaries at risk and certainly putting them at risk of being served malware coctails, you are ok with the admins not discovering it because you blame the user whose account was compromised?
How about blaming Linux security for attackers being able to root multiple systems from a user account.
And do you feel comfortable that just because you can blame a user it is ok that the admins did not notice anything was wrong before some of the malware emitted error messages which should not come from a server system?
Secure Boot could have prevented the compromise from going on for so long. Who is stupid, really?
Perhaps the fear is that if the patch is not merged, Microsoft will revoke the certificates that have been used to sign mainstream GNU/Linux distributions.
Microsoft doesn't control the certificates, VeriSign does, Microsoft can't just 'revoke' certificates and stop SecureBoot from loading them, they don't control any of that.
Yes they do. The bootload'ers used for booting Linux are signed by Microsoft. The Linux community *could* work with vendors do have a "Linux" certificate installed in the firmware which would allow other boot-loaders to boot. But given the number of vendors that has been deemed impractical. Instead Linux distros (and Matthew Garett) have created boot loaders/shims which are chain-loaded from Microsofts boot-loader. As such they need a MS key.
Presumably MS has a number of restrictions on how such a boot loader works. For instance, they probably require that the user is being made aware of the fact that they boot a non-Windows OS. If they didn't (and allowed silent boots) a rootkit could simply install itself as a chained, silent OS and then boot Windows from within a VM. A rootkit.
Secure boot isn't. There is no point in hacking our way into Secure boot because it isn't secure, period. There is always a way around every security design
Right. Why do we bother with security in the first place? Let's just disable security features on every system because they will be circumvented anyway. What an absurd argument.
and hobbling the industry with a proprietary technology isn't going to help anyone but incumbent large players.
Secure Boot isn't proprietary. It is specified bye UEFI where several of the Linux distros have been represented. Not that you'd know from the hyperbole by some of them, MJG included.
Secure Boot is nothing more than an attempt by Microsoft and other entrenched players to exclude smaller companies. The only secure idea at Microsoft is Linux!
Personally I'd like my bank, my government, the military, the SSL issuers to set up their systems so that they'll know if their systems (on which I depend) have been compromised. Have you forgotten that kernel.org, linuxfoundation.org and several other LF operated sites were thoroughly root'ed for a almost a month without them noticing it? It took a coincidence and a mistake on part of the attackers for the admins to discover. Without the mistake, those system could very well have been root'ed to this day.
Secure Boot *directly* addresses that problem: If your system has been compromised, you'll want to know as soon as possible. Secure Boot will refuse to boot a compromised system.
Your comments about kernel control and security is spot on. I don't get the "we already got enough security" argument at all. It's like the mantra that Linux somehow is inherently the most secure OS imaginable has gotten the best of some of the community and they actually started believing that there's nothing more to do.
Sure, it was invented by Microsoft, and Microsoft (on x86) enforces the user's ability to do an untrusted boot.
Not sure it was invented by Microsoft. It was specified by UEFI and certainly *pushed* by Microsoft. Parts of the Linux community in an effort to paint everything MS does as inherently bad tried to label Secure Boot bad and then let Microsoft own it. Fortunately that has largely failed.
But Linux has signed bootloaders which allow the user to boot their own self-signed kernels. Given this, why shouldn't Linux have the ability to continue a chain of trust?
Given that Linux is being trusted with large part of our infrastructure I'd say that Linux pretty damn well *must* guarantee a chain of trust. I do not want my bank, government, SSL issuers etc. to be operating compromised systems. As this story illustrates there is still some way to go. When Windows boots it *only* trusts MS signed cabinet files where both executable code, resources and configuration resides. I believe that there's also a weakness in Linux where the configuration can be compromised outside the signing support of some distros.
Slashdot Mirror
somelabel: if(something_happened() process_it(); wait_until_next_event_is_ready(); goto somelabel;
This would have close to zero latency, and would eat precisely zero processor time when idle.
Still bad. You are tying up precious resources such as processes, threads and memory. In general it is better to:
1. Register for events, e.g by filling a jump table and register it with the OS. Each item in the jump table represents a well-known function such as "device arrived", "system goes to battery power", "device removed" or "system shutting down".
2. return and relinquish any resources such as process, threads, memory, handles.
3. When a routine is invoked by the OS then perform the function as quick as possible and return. Don't tie up resources.
But on the flip, Microsoft's hardware abstraction layer is a terrible, horrible, implimentation that makes every access from userspace terribly expensive.
And worse? Some of the documentation specifically says they want it that way! On purpose!
Citation needed.
Windows actually has a rather sophisticated driver model which allows many drivers to be implemented in user mode or at least be divided so that big parts can run in user mode. This improves both stability and security. A relevant type of drivers in this context is bus drivers, specifically bus drivers for USB. These drivers will discover new devices on the USB bus *regardless* of their make, capability etc. The bus driver til inform *your* driver when a device arrives. No need to scan or poll for devices. If you do it right you can just sit there and wait to be informed. No need to poll, no need to even tie up a thread in waiting state.
That is all in the documentation:
Types of WDM Drivers
Function drivers
An example
So which part of the documentation did you read?
Everytime I have to work with HAL I'm filled with a strong urge to strip all my clothes off, burn them, then take a cold shower while shivering up in the corner, scrubbing my skin raw, chanting "must...wash...away...the sin..."
Maybe you should find another line of work?
It knocks both DRM and Windows in one sentence. Which is popular on slashdot.
Facts don't matter, accuracy doesn't matter. Comments can be outright lies (like this one) and still achieve the highest ranking as *informative* just because it plays to a popular myth.
No, games are *not* run with admin rights. No they do *not* need to run with admin privileges, not even to use DRM. Especially not the online DRM variety that steam uses.
So the minimum requirement is that you can delete all the keys.
Wrong. There is no requirement that you *explicitly* can enter UEFI Setup Mode. The system vendor MAY allow such an explicit option, but the MINIMUM requirement is that he MUST allow Setup Mode to be entered by deleting all keys.
Read what you quoted again, please:
1) It SHALL be possible for a physically present user to use the Custom Mode firmware setup option to modify the contents of the Secure Boot signature databases and the PK.
2) This MAY be implemented by simply providing the option to clear all Secure Boot databases (PK, KEK, db, dbx), WHICH puts the system into setup mode.
So the owner of the system can ALWAYS enter setup mode. He may have some direct way to do that, but he can ALWAYS delete the key databases, which will cause the system to go into UEFI Setup Mode.
"If the user ends up deleting the PK then, upon exiting the Custom Mode firmware setup, the system is operating in Setup Mode with SecureBoot turned off."
So when you delete the keys, SecureBoot is turned off.
Correction: When you delete the keys the system enters Setup Mode. If you choose to exit the automatically invoked setup mode WITHOUT entering a new platform key, THEN secure boot is turned off. Which makes perfect sense as there are now no keys in the firmware which could validate anything.
There's also an option to always put the Microsoft key back in place. But that's it.
No, you can enter ANY key into the Platform Key database. From http://lwn.net/Articles/447381/ : "Before a PK is loaded into the firmware, UEFI is considered to be in "setup" mode, which allows anyone to write a PK to the firmware. Writing the PK switches the firmware into "user" mode. Once in user mode, PKs and KEKs can only be written if they are signed using the private portion of the PK, though KEKs can be freely written during setup mode. Essentially, the PK is meant to authenticate the platform "owner", while the KEKs are used to authenticate other components, like operating systems."
At no point does it guarantee that you can enter an arbitrary key and keep secure mode on.
And you are wrong. The PK (Platform Key) is the "owner" key. You can enter your own key if you like.
Which is basically what I said.
But you were mistaken.
And "possible" can be provided by means of, say, a supplied disk available at extra cost from the manufacturer that has to be inserted for such action to be taken at all.
Lip service.
So, basically you are spreading FUD: *Fear* that it may incur extra costs, *uncertainty* because you choose to disregard facts and present your own speculation and conjecture as facts, and finally *doubt* as to the "real" intentions behind secure boot.
I thought the "embedded" Flash of IE is similar to Chrome's embedded Flash. Meaning Microsoft maintains its own build of Flash like Google maintains its own Flash. So it's up to Microsoft to fix any security issues and not rely on Adobe to release a patch to the consumer. So it could be a good thing like Chrome or a terrible thing like IE6.
They are similar. It is still Adobe developing Flash, but they coordinate releases with both Google (for Chrome) and Microsoft (for IE) so that vulnerabilities are not implicitly revealed through one version where an attacker could version compare and reverse engineer to figure out the vulnerability.
Both browsers sandbox the Flash plugin. In the case of IE the Flash process runs under low integrity mode (protected mode).
On top of that, the "embedded" Flash is only available to a Microsoft-controlled white-list of sites. An attacker cannot simply set up a fake site with Flash attack code. IE will refuse launch the embedded Flash for all but the white-listed sites.
On Windows 8 the "embedded" Flash is only available in the Metro^h^h^h^h^hModern version of IE. The desktop version still require explicit installation of Flash if you want to use it. This latter is the situation with IE10 on Windows 7 as well.
Apple still maintains their own Java 6 until EOLed
FYI, Java 6 EOLed now, Feb. 2013, no longer supported by Apple
For your information: http://support.apple.com/kb/HT5666 :"Multiple vulnerabilities existed in Java 1.6.0_37, the most serious of which may allow an untrusted Java applet to execute arbitrary code outside the Java sandbox. Visiting a web page containing a maliciously crafted untrusted Java applet may lead to arbitrary code execution with the privileges of the current user. These issues were addressed by updating to Java version 1.6.0_41. For Mac OS X v10.6 systems, these issues were addressed in Java for Mac OS X v10.6 Update 13"
Apple patched this vulnerability on feb 19th 2013. After systems had been compromised. Macs which had been upgraded from previous versions where Java was installed *still* has Java installed. Apple obviously felt obliged (as in "egg on their heads obliged") to patch this one. OS X systems all over the world have been compromised because of Apples approach to security, especially Java security.
This payload was Mac specific, and Mac computers were the only one affected.
Well, that's not what TFA says, nor any article I've read about it... but what possible reason would you have for making shit up?
Oh? Try read this one (or just the excerpt):
http://news.yahoo.com/microsofts-macs-hacked-java-attack-045502922.html : "Even more significantly, it wasn't Microsoft's Windows computers that were hacked so much as it was Microsoft's Macs."
Glad I could help.
It wasn't just the Macs. This was an attack on the Oracle java browser plugin, not an attack on a specific platform.
Troll less, recoiledsnake.kthxbai.
Yes, it was just the macs. The attack vector was a Java vulnerability, but the payload is always OS specific. Some attacks have been known to serve different payload after sensing the OS. But not this one. This payload was Mac specific, and Mac computers were the only one affected.
Coincidentally, the Java vulnerability exploited in the attack had been patched by Oracle several weeks before. But the vulnerability was still in the Apple maintained Java 6 (Apple still maintains their own Java 6 until EOLed - Oracle has only committed to maintain Java 7 on OS X).
This is all Macs and all Apple.
Funny, if it's Windows that gets hit, the first thing said around here is that the OS should be secure enough to prevent such attacks.
That's because the attacks are usually around IE or open ports. So of course people would blame the OS for the security failure.
If the attacks are "usually" around IE or open ports, when was the last such attack?
Use dism.exe. It will let you capture freshly installed machine - even with installed applications - back into an install image, i.e. slipstreaming. From the install image it will work exectly like the original image, only it will have all of the installed service packs, updates and patches already installed.
not if it phones home
Yeah.
But it doesn't.
Microsofts activation technology relies on local hashcodes generated from fingerprinting properties of devices. It allows for a certain amount of changes over time, e.g. changing disk. It contacts the activation servers during activation, but after that it *never* phones home.
It would be better if it was totally free of this DRM restricting users. I believe that it is a fair expectation by the customer expects that he *bought* the product. Most regular customers do not get the difference between a license to use (and in this case restricted to a single device) and a product be owns.
DRM is bad. But this one does not phone home.
Why exactly have you included steps 3 and 4? The way I see it, you can jump from 2 straight to 5!
rootkit.
Microsoft surely knows that Secure Boot won't affect savvy nerds from converting to Linux. They also surely know that Linux is still growing organically, relying on word-of-mouth and firsthand try-before-you-buy experience.
You are seriously delusional. "Converting" to Linux is not, has never been and will never become a threat to Microsoft. Right now Microsoft is pressured on other fronts, such as desktop PC losing relevance, not being on the boat on mobile and not competing effectively in the tablet game.
You are trying to wage last decades battle. Microsoft does not feel threatened by Linux on the desktop *at* *all*. Get real. The threats to Microsoft do not come from conversions in the x86 space, the come from vertical players and mobile, like Chromebooks, tablets, smartphones.
Note how *all* of these emerging platforms have more restricted app models, and especially *boot* models. Microsoft is simply evolving their primary platform to match the features and security (from closed and semi-closed gardens) of the threatening platforms.
The threat to Microsofts desktop business is *not* Linux. Even though Linux has evolved in that space and on the surface appears to be able to go head-to-head, Microsoft Windows is still *much* more mature than any desktop Linux. Consider for instance group policies, restart manager, volume shadow service, various troubleshooting guides, shims for both application and device compatibility etc. The real threat is that the desktop become irrelevant.
If the desktop is perceived as less secure than an online counterpart, Microsoft will be losing. They *need* to ensure secure boot. It is not a anti-Linux move at all. You are flattering yourself. And being stupid.
It's sandboxed like Chrome: http://www.webmonkey.com/2012/06/flash-firefox-play-together-in-new-security-sandbox/
Flash in Firefox is only sandboxed like Chrome on Windows:
But not on OS X. Chrome on Windows uses UAC/MIC too (and also puts in place some extra sandboxing features). Note, Firefox itself on Windows is still not sandboxed. This sandboxing only applies to the Flash plugin, not the browser itself and not to other plugins. An exploit running on Windows is running under low-integrity mode. It can not write anywhere to infect the system.
Firefox on OS X is not sandboxed; not the browser itself, not plugins in general and not Flash by itself. An exploit runs as the current user once it is running shell code. It runs with the user privileges and can write anywhere the user can, i.e. it can infect the local user account.
Does this bug also affect users of those OS's, because last time I heard
a) Adobe isn't offering a flash package for current android
b) Adobe isn't offering updates to the Linux flash version.
I'll assume that Linux users can have the vulnerable version, is there something in the OS that makes them immune or were they just not mentioned?
The 1st paragraph of TFA:
Short of using SELinux or apparmor on Linux (and live with the consequences), there is nothing to prevent an exploit using these vulnerabilities through e.g. Firefox or other non-sandbozed browsers. IIRC Chromium uses a sandbox which would prevent the attack from infecting your account.
Windows uses low-integrity mode to sandbox Flash in browsers which is why the attackers try to use an alternate (and lower yeilding) attack vector through older versions of Microsoft Word (Word 2010 sandboxes the entire document including any Flash content if the document was downloaded from an untrusted source or received through an email)
Wrong. I am the supplier of the inputs for the product that is being packaged by Google and sold to advertisers, and Gmail is (one of many parts of) the payment Google provides to me in return for providing those inputs.
The "input" you supply is your privacy. You sell your (and your contacts) privacy to google for access to their services. That's the transaction. When somebody sends you an email, Google scans it to learn things about you and your contact who sent it.
If the email mentions a particular brand of shoes, Google may start advertising those to you when the contacts birthday approaches. They may also use the information sent to you in confidence to target advertising to your contact.
You are selling your privacy, and your contacts privacy. For access to "free" services.
We see here how the Windows platform has been battle hardened to the point where the attackers have to resort to lower-yield secondary attacks. Head-on attacking Flash on Windows does not get the attacker very far because of the security advancements such as Mandatory Integrity Control (MIC). That's why the attackers try to exploit it in contexts where MIC does not prevent system infection, such as through older versions of Microsoft Word through emails.
OS X is still wide open to such head-on attacks when a vulnerability exists, especially Firefox because Mozilla has steadfastly refused to put in place a proper sandboxing barrier. Even Safari has some sandboxing in the latest version of OS X.
Firefox not. A vulnerability in Firefox or one of its plugins means significant risk of successful exploits.
Flash on Windows executes in a low-integrity process. Even if a Flash vulnerability is exploitable and shellcode gets to execute in the Flash host process, it still cannot write anywhere or interact with higher integrity objects because of mandatory integrity control (MIC) which was introduced with Vista.
The upshot: Attackers have to try secondary routes on Windows where the conversion rates are much, much lower. And this specific attack vector will not work on Word (or other Office applications) since Word 2010. Since the 2010 versions, internet downloaded documents are also opened in low-integrity mode, meaning that even here the shellcode would be similarly restricted.
Windows users are targeted with Microsoft Word documents delivered as an email attachments which contain malicious Flash content
Why?
Probably because of Windows sandboxing Flash through low-integrity mode. Even if you get to exploit a Flash vulnerability and execute your shell code on Windows, the code is still severely restricted in what it can do. Code executing inside of a low-integrity process can still not infect a system as write-ups (writing or interacting with a higher integrity object/process) are denied.
They could as easily infect you with a macro. Who in their right mind opens a Word doc from and unknown source, especially when Windows warns you when you start to open a word doc in Outlook (we use Outlook at work).
No, infecting with a Macro is more difficult since the last several versions of Word. Word will not automatically run macros and also has an internet-origin policy whereby documents received through Outlook or other email clients or downloaded using a browser is tainted with the "internet zone". You have to dismiss several warnings to run macros from such a document. But if Word will run Flash content (show the animation) and a vulnerability can be exploited, shell code can run as a user.
That is, until Word 2010 which *also* runs in low-integrity when viewing content tainted with the internet zone. Since Word 2010 the shell code will still be confined to the low-integrity sandbox.
You'll find hundreds and hundreds of security patches with more being released every Tuesday. If you really want to see a leaky sieve of an OS look no farther than Windows.
Patch tuesday is not "every tuesday". It's the second tuesday of every month, i.e. 12 tuesdays per year as opposed to 52 as you claim.
Patches are not just security patches, they also include stability patches, compatibility patches, language updates and more.
Comparing Java to a full operating system is a little disingenuous too.
If you must compare to something then you should compare Java to .NET Framework. But I wouldn't recommend you doing that if you like Java.
Java has consistently many times more security problems than .NET Framework, even if you compare just JRE with the *full* .NET framework (which include enterprise features comparable to what you get with *both* JSE + JEE).
Java SE 7 (released 2011-07-28): 88+50 (adding these latest vulns) = 168 vulnerabilities (source: http://secunia.com/advisories/product/37734/) .NET 4 (released 2010-04-12): 31 vulnerabilities (source: http://secunia.com/advisories/product/29592/)
If you take the availability period into account (vulnerabilities does seem to be discovered continously):
Java SE 7 has on average experienced 110 vulnerabilities per year. .NET Framework 4 has on average experienced 11 vulnerabilities per year.
That is ten times more vulnerabilities in a Java base class library which does even cover the same functionality as the .NET Framework does.
I think the best thing about a decentralized model is the guys who run release engineering can run their own clone and pull when it suits them. And developers can work on branches, merge locally and test everything correctly to their own satisfaction before pushing. When everything is centralized it is not uncommon to see some email telling people a particular branch is locked for a merge, or for a build and it can go on for hours or days.
But in TFS you can automate all that. TFS can build by label, by changeset or simply by point-in-time. Developers can pull specific versions out locally, also without branching. Only incompetent build engineers would ask developers to refrain from checking in. Really. Even as a developer I can request such a build.
Sounds like they are going to use it internally. That still doesn't mean that you will be able to report bugs to MS developers.
Not likely. They already have TFS (or rather TFVS) which is pretty powerful. TFS is centralized and not based on a distributed model like Git. But each model has core advantages over the other.
Being centralized it is easier to create overview and centralize building, integrate with project management, testing, bug reporting etc. with TFS. But TFS is also focused on creating a single product and doesn't lend itself as easily to forking projects like Git does. TFS does branching and merging very, very well, but the central repository has to know about the branches, i.e. it is not so easy to create local ad-hoc branches.
Git is based on a decentralized model which is very, very good when you have a fluent number of products branching off from a repository. Git doesn't automatically expect a branch to be merged at some point, indeed the repository does not *know* about branches, it only knows about change/patch sets. However, the distributed model also means that there is no one central repository and you cannot use the repository to track *ongoing* work (who's working on what).
In some cases Git is better. In other cases the TFS model is better. If you have a distributed development model go with Git. If you have a very centralized development model go with TFVS.
They did the smartest thing they could have done, which was to put an Apple-style interface on a free, high quality implementation of an operating system that was more than powerful enough to hang with the industry leaders, well understood by geeks, and which contained, essentially, the reference implementation of the protocols that the internet runs on.
Were you around in 2001? I don't think "high quality" is a term anyone would use to describe those first versions of OS X. It was slow, user interface sluggish, riddled with kernel panics. Apple actually had to offer a free upgrade to 10.1 - which was still slow and sluggish but somewhat more stable. OS X eventually grew into a high quality OS, but those first versions were certainly not. Until Tiger it was kind of a joke, really.
"They suspected that the attackers somehow compromised the system of one of the users and used his access to the systems."
I heard something about the lazy idiot between the screen and the chair. Secure boot doesn't and can't fix stupid.
So when a system is compromised for most of a month, potentially putting users who download binaries at risk and certainly putting them at risk of being served malware coctails, you are ok with the admins not discovering it because you blame the user whose account was compromised?
How about blaming Linux security for attackers being able to root multiple systems from a user account.
And do you feel comfortable that just because you can blame a user it is ok that the admins did not notice anything was wrong before some of the malware emitted error messages which should not come from a server system?
Secure Boot could have prevented the compromise from going on for so long. Who is stupid, really?
Perhaps the fear is that if the patch is not merged, Microsoft will revoke the certificates that have been used to sign mainstream GNU/Linux distributions.
Microsoft doesn't control the certificates, VeriSign does, Microsoft can't just 'revoke' certificates and stop SecureBoot from loading them, they don't control any of that.
Yes they do. The bootload'ers used for booting Linux are signed by Microsoft. The Linux community *could* work with vendors do have a "Linux" certificate installed in the firmware which would allow other boot-loaders to boot. But given the number of vendors that has been deemed impractical. Instead Linux distros (and Matthew Garett) have created boot loaders/shims which are chain-loaded from Microsofts boot-loader. As such they need a MS key.
Presumably MS has a number of restrictions on how such a boot loader works. For instance, they probably require that the user is being made aware of the fact that they boot a non-Windows OS. If they didn't (and allowed silent boots) a rootkit could simply install itself as a chained, silent OS and then boot Windows from within a VM. A rootkit.
Secure boot isn't. There is no point in hacking our way into Secure boot because it isn't secure, period. There is always a way around every security design
Right. Why do we bother with security in the first place? Let's just disable security features on every system because they will be circumvented anyway. What an absurd argument.
and hobbling the industry with a proprietary technology isn't going to help anyone but incumbent large players.
Secure Boot isn't proprietary. It is specified bye UEFI where several of the Linux distros have been represented. Not that you'd know from the hyperbole by some of them, MJG included.
Secure Boot is nothing more than an attempt by Microsoft and other entrenched players to exclude smaller companies. The only secure idea at Microsoft is Linux!
Personally I'd like my bank, my government, the military, the SSL issuers to set up their systems so that they'll know if their systems (on which I depend) have been compromised. Have you forgotten that kernel.org, linuxfoundation.org and several other LF operated sites were thoroughly root'ed for a almost a month without them noticing it? It took a coincidence and a mistake on part of the attackers for the admins to discover. Without the mistake, those system could very well have been root'ed to this day.
Secure Boot *directly* addresses that problem: If your system has been compromised, you'll want to know as soon as possible. Secure Boot will refuse to boot a compromised system.
Your comments about kernel control and security is spot on. I don't get the "we already got enough security" argument at all. It's like the mantra that Linux somehow is inherently the most secure OS imaginable has gotten the best of some of the community and they actually started believing that there's nothing more to do.
Sure, it was invented by Microsoft, and Microsoft (on x86) enforces the user's ability to do an untrusted boot.
Not sure it was invented by Microsoft. It was specified by UEFI and certainly *pushed* by Microsoft. Parts of the Linux community in an effort to paint everything MS does as inherently bad tried to label Secure Boot bad and then let Microsoft own it. Fortunately that has largely failed.
But Linux has signed bootloaders which allow the user to boot their own self-signed kernels. Given this, why shouldn't Linux have the ability to continue a chain of trust?
Given that Linux is being trusted with large part of our infrastructure I'd say that Linux pretty damn well *must* guarantee a chain of trust. I do not want my bank, government, SSL issuers etc. to be operating compromised systems. As this story illustrates there is still some way to go. When Windows boots it *only* trusts MS signed cabinet files where both executable code, resources and configuration resides. I believe that there's also a weakness in Linux where the configuration can be compromised outside the signing support of some distros.