Ask anyone involved - even whitehats - and you are likely to be told that the demand and renumeration for exploits on the open market is higher than it is for submitting it and expecting a bounty.
I work with a lot of such people, and their response is that remuneration on the dark side is iffy and dangerous, and there's the constant threat of getting caught and prosecuted. Their opinion is that -- excluding spook operations -- the black hat side is small and relatively untalented.
I guess maybe it depends how you classify the government-funded stuff. Personally, I don't consider it either white or black, but somewhere in between. And I don't think it attracts the best, though perhaps quantity counts as much as quality. There was a time when the NSA attracted the best, but that was before Snowden.
The DMCA doesn't allow for take downs to occur without actual evidence.
Go read the law. The DMCA requires takedowns to occur without evidence. If a host receives a DMCA takedown notice, which is nothing more than a letter asserting ownership, the host is required to take the material down. Of course, the uploader can file a counter-notice, in which case the host can (but is not required to) put the material back up. And then the claimant and the uploader go to court, where actual evidence comes into play.
More precisely, Google's demonetization and reassignment of ad revenue are a kindler and gentler approach that Google negotiated with big content owners.
To be clear, it's a way for Google to keep collecting their cut regardless of who owns the content.
Sure, it works better for everyone, including Google.
The supreme court of the United States has definitively ruled that patentable items can no longer be protected by copyright once the patent has been expired.
I understand these words, but they make no legal sense when strung together this way. Patent and copyright are two entirely different things. Patents cover ideas, copyrights cover expressions fixed in a tangible medium. I see no way that any patentable item could ever be covered by copyright, or how expiration of any patent could in any way be relevant to any copyright.
The case in question is a copyright issue. Assuming he made the white noise himself (whatever sort of machine he used to make it), and assuming that white noise is copyrightable at all (which I strongly doubt), then he owns the copyright in his recording. The fact that Google's algorithm found that it is highly similar to tracks owned by others (again, assuming they actually can be copyrighted) does not mean that his track is an infringing copy, just that it sounds similar.
Anyway, yes, he should file a dispute and explain the situation.
Except there are five claims against him from four different sources. If the claims are based on copying, then at least three others copied from the exact same source and have filed violation claims based on pilfered content.
I doubt anyone copied anyone. If the audio track recognition algorithm looked for exact copies, it would miss a huge percentage of actual infringement, and be trivial to work around. So it does something cleverer and looks for audio tracks that sound sufficiently alike. White noise tracks all sound alike, even if they don't have a single bit in common.
The DMCA does not require this. It requires services like YouTube to implement a takedown process with particular criteria. Google's demonetization and reassignment of ad revenue are its own creations, unmoored from the law's requirements.
More precisely, Google's demonetization and reassignment of ad revenue are a kindler and gentler approach that Google negotiated with big content owners. The strict DMCA process would be a pain for content owners (but the big ones would still do it!) and would result in Google taking videos down completely, rather than just reassigning revenue. The system isn't perfect, not only because the automated matching is imperfect, but also because it doesn't serve small content owners as well as big ones. But for the majority of cases it's a better solution than merely following the law.
Spectre is a red herring - there is no known way it can be exploited.
Yet.
non-Intel users have not been compromised
So far.
Frankly, this whole hoopla about Spectre seems like a well orchestrated deflection stunt by Intel PR operations. And your posts smells a bit of sockpuppetry.
Intel had nothing to do with it; all three issues were found by Google Project Zero (who didn't name them; GPZ doesn't do silly vulnerability marketing games), and then independently by other researchers.
Note that I'm not trying to defend Intel. I'm an AMD fanboy from way back, and I'd love to see this give AMD a major boost in sales for a few years. But let's not get overconfident. This is a brand new class of attack and few security researchers have focused on it yet. There will be more attacks.
Note that the attack does allow code to spy on memory in the same process on AMD. This seems at first glance to be a non-issue... until you consider that lots of processes -- like your web browser -- run JITed code from untrusted sources. Malicious Javascript able to read any data from the browser process is a big deal. Even if your browser uses a separate process per tab, this means that resources on a page can break the same origin policy. With Chrome you can optionally enable strict site isolation which will run the content from every origin in a different process, but that comes at a performance cost.
I leased my Nissan Leaf as well, until I bought it. In 2016 my lease was expiring and I extended for a year. In 2017 it expired and I bought the car.
This all worked out to be *extremely* economical, mostly because Nissan badly mis-estimated the resale value. I leased a $35K vehicle for ~$210 per month for 36 months (no cash down, though there were some documentation fees and sales tax that had to be paid up front on the $7500 federal tax credit). When the lease ended, I paid $6000 to buy the car. 36 * 210 + 6000 = 13,560. Oh, and my total maintenance expenses have been one set of replacement tires, ~$200.
As for battery life: I have 60K miles on the car and haven't lost more than about 10% of my range. The battery capacity degradation curve is steepest early on, so I expect the car to have >80% of its range basically forever.
I have $1K down on a Model 3. I'll probably lease it as well, since I don't think the EV technology progress curve has flattened out significantly yet.
- on Intel CPU, you have a violation of boundary separation : an end-user application could access information leaking out of the kernel. - on AMD CPU, this does not happen : you only access information on the same side of the separation boundary.
... so far.
All of the people saying "Ha! Intel only! AMD is better!" are missing the point. The concern isn't only about the specific attacks devised so far. The concern is that we have a whole new class of attack, exploiting a fundamental feature of the architecture of all modern CPUs. Yes, AMD is less vulnerable to the attacks so far devised, but that is an accident. AMD didn't design to protect against this class of attack, because they didn't know about it.
As Bruce Schneier likes to say: Attacks always get better. It's not at all unlikely that new variants that AMD is vulnerable to will be found, including some that perhaps Intel is not.
Until we revisit CPU design and take steps to ensure that cache changes made by one process can't be detected by another process, there will be a series of ever-more-clever attacks devised that exploit this hardware side channel.
OTOH, part of me is an old AMD fanboy, going back decades, and would love to see this give AMD a big boost. If the required mitigations on Intel are as damaging to performance as some tests indicate, AMD could find itself as the performance champion again. I don't think it looks like that's going to happen based on the current exploits, but I can hope;-)
If you're sharing hardware with an unknown number of other tenants and have free reign on your VM, yeah this is a huge security hole.
Or running code you download from the web.
As far as web-servers using java script to read your kernel mode memory... yeah, not good, but then if you're visiting a illegitimate website you don't trust, you probably should be in a sandboxed VM anyway. Evil sites are evil.
Good sites can also be evil. If your connection isn't secured, any hop between you and the server can feed you malicious code. If the server isn't well-secured, it can be hacked to send you malicious code. If the server developers just get a bad version of a legitimate library, it can send you malicious code. And so on.
This makes VMs a bit less bulletproof.
A lot less. Given the right gadget in the hypervisor, this could be used to read hypervisor memory.
It's not the end of the world. The attacks aren't terribly easy to mount, and we can apply mitigations to make them even harder. But remember... this is just the first step. This is an entirely new class of side-channel attacks, so the initial vulns are just the beginning. More is coming.
Ultimately, we need new CPUs that have per-ring caches, or swap caches on privilege level context switch, or perhaps unwind cache state when they unwind a pruned speculative execution path. But this class of vulnerability is a new one that security engineers are going to have to guard against in software until hardware fixes are available, and we don't yet fully understand the implications.
Sort of, but not exactly. It's about having a product in every price point. The value of a robot vacuum is not the same to every person, both because some get more value from it, and because some value money less. The Laffer curve says that to maximize profit with a single product you lower the price until the marginal increase in profit due to volume matches the marginal decrease in profit due to lower sale price. But if you do that, you're leaving money on the table because a lot of people would have been willing to pay more.
The fix is to have a range of products at different price points. To some extent you do this by making versions of varying quality, so the higher-priced units cost more to make and are better (but still have roughly the same profit margin, which means more actual profit for the higher-end versions). But there's a limit to how much real differentiation you can make. The solution is to introduce lots of small feature differences, including deliberately disabling features on some models. Buyers will almost always get the most expensive model they can afford, or maybe just one step down, as long as there is some difference that they think they might like to have.
The most, er, interesting examples of this are when companies sell the exact same product at different price points. A factory may put two different logos on the same product and sell them at different prices, for example. IBM was famous back in the day for selling "single-CPU" mainframes that were actually delivered with four CPUs on board. If you wanted to upgrade your computer and make it faster, they sent a guy out to turn on some more cores in exchange for a hefty fee. Or later, they turned them on for you remotely. And if your check bounced they turned them right back off.
Coupons and other sorts of discounts are another tactic. You can set the normal price high but occasionally sell it for less via some mechanism that is just complicated or difficult enough that those who can afford the higher price won't bother.
Depending on your perspective, these shenanigans are either cheating or giving the customer what they want at the price they want to pay.
Of course, mass personalization may mean that companies don't have to do this so much any more. Rather than having a half-dozen different products at different price points, they can make only one... but based on knowing who you are they can offer you the highest price you're willing to pay.
Only if you want to drive a used car. If you're going to buy a new car either way, and your driving patterns fit the profile that current EVs work well for (which is becoming less of an issue; 200+ miles range works for most people), then the total cost of ownership calculation for EVs gets to be pretty good even without tax credits, and quite compelling with them.
And if you don't mind driving a used car, you can buy a used EV. It's pretty disingenuous of you to compare new EVs to used ICEVs.
It's not immediately clear exactly why Google is building a new operating system...
Possibly to un-encumber themselves from the GPL? I note that Fuchsia's licenses are a mix of MIT, BSD, and Apache. This would potentially allow them to adapt the OS to just about any environment without having to release the source code.
Note that those are the same FOSS licenses Google uses on all of its open source projects. I wouldn't read anything into those choices.
Other than GPL isn’t one of them?
Right, GPL isn't one of them. The point is that the same licenses are used by Google on lots of stuff, for which they don't hold back source code, so there's no reason to assume that the same choice of licenses indicate that Google is planning on holding back source in this case.
For that matter, they could use the GPL without losing the ability to hold back source when they want to. The owner of GPL'd code is not required to abide by the terms of the GPL. That only applies to other people who want to use it. In many cases, even the original author is eventually constrained because of third party contributions which they don't own or have any license to other than the GPL. But Google isn't accepting third party contributions now and even if they were to do so in the future the standard Google open source contributor agreement requires that contributors grant Google an unlimited license to do anything at all with the code, so that wouldn't restrict what Google can do either.
In Canada, there's a crack down on some small business abuse that gives way more advantages over salary workers.
Yes, governments have to be careful to ensure that businesses aren't covering employee (or owner) expenses while claiming them as business expenses. The US IRS is quite good at this.
Indeed. This is the only case I know of where Project Zero delayed beyond their 90-day disclosure window. They gave people six months to patch this time, because there was just so much to be done by so many organizations.
If someone can run a particular pattern of code on your system, all mapped memory is readable to them.
Not quite that epic. If someone can run a particular pattern of code on your system, all mapped memory accessible to the process in which the particular pattern of code is run is readable to them. If they can make it happen in, say, the OS kernel, of course, which has access to everything... that's pretty epic.
Based on other comments above, there is a fair chance you misunderstand the nature of the bug. It is reported that AMD validates requests for speculative execution before executing them, and Intel validates them afterwards. The bug is supposedly that it's possible to read the results of the speculative execution before the Intel chip notices that they were improperly executed. If that is so, then the AMD chips do *not* have this particular bug.
And low and behold, that's often what has happened
Aside: you may (or may not) be interested to know that the phrase is "lo and behold". The "lo" isn't about the height of something, it's an exclamation or interjection from Middle English, likely a shortened form of "look" (which was pronounced more like "loke"). So "lo and behold" means "look and see".
Slashdot Mirror
Ask anyone involved - even whitehats - and you are likely to be told that the demand and renumeration for exploits on the open market is higher than it is for submitting it and expecting a bounty.
I work with a lot of such people, and their response is that remuneration on the dark side is iffy and dangerous, and there's the constant threat of getting caught and prosecuted. Their opinion is that -- excluding spook operations -- the black hat side is small and relatively untalented.
I guess maybe it depends how you classify the government-funded stuff. Personally, I don't consider it either white or black, but somewhere in between. And I don't think it attracts the best, though perhaps quantity counts as much as quality. There was a time when the NSA attracted the best, but that was before Snowden.
The odds of a whitehat finding any exploit first -- is probably much less than 50%.
What is your rationale for this claim?
No known exploits in the wild yet.
How many unknown exploits in the wild?
Oh, right, we don't know. If we did, they wouldn't be unknown.
He has found/created a small pond
The world's most widely-used operating system kernel is hardly a "small pond".
You ignored the rest of the sentence you quoted. You should read it, since it's the real point.
The DMCA doesn't allow for take downs to occur without actual evidence.
Go read the law. The DMCA requires takedowns to occur without evidence. If a host receives a DMCA takedown notice, which is nothing more than a letter asserting ownership, the host is required to take the material down. Of course, the uploader can file a counter-notice, in which case the host can (but is not required to) put the material back up. And then the claimant and the uploader go to court, where actual evidence comes into play.
More precisely, Google's demonetization and reassignment of ad revenue are a kindler and gentler approach that Google negotiated with big content owners.
To be clear, it's a way for Google to keep collecting their cut regardless of who owns the content.
Sure, it works better for everyone, including Google.
Did YouTube give you a license to copy and distribute the music they provided for you to use in your video?
The supreme court of the United States has definitively ruled that patentable items can no longer be protected by copyright once the patent has been expired.
I understand these words, but they make no legal sense when strung together this way. Patent and copyright are two entirely different things. Patents cover ideas, copyrights cover expressions fixed in a tangible medium. I see no way that any patentable item could ever be covered by copyright, or how expiration of any patent could in any way be relevant to any copyright.
The case in question is a copyright issue. Assuming he made the white noise himself (whatever sort of machine he used to make it), and assuming that white noise is copyrightable at all (which I strongly doubt), then he owns the copyright in his recording. The fact that Google's algorithm found that it is highly similar to tracks owned by others (again, assuming they actually can be copyrighted) does not mean that his track is an infringing copy, just that it sounds similar.
Anyway, yes, he should file a dispute and explain the situation.
Except there are five claims against him from four different sources. If the claims are based on copying, then at least three others copied from the exact same source and have filed violation claims based on pilfered content.
I doubt anyone copied anyone. If the audio track recognition algorithm looked for exact copies, it would miss a huge percentage of actual infringement, and be trivial to work around. So it does something cleverer and looks for audio tracks that sound sufficiently alike. White noise tracks all sound alike, even if they don't have a single bit in common.
The DMCA does not require this. It requires services like YouTube to implement a takedown process with particular criteria. Google's demonetization and reassignment of ad revenue are its own creations, unmoored from the law's requirements.
More precisely, Google's demonetization and reassignment of ad revenue are a kindler and gentler approach that Google negotiated with big content owners. The strict DMCA process would be a pain for content owners (but the big ones would still do it!) and would result in Google taking videos down completely, rather than just reassigning revenue. The system isn't perfect, not only because the automated matching is imperfect, but also because it doesn't serve small content owners as well as big ones. But for the majority of cases it's a better solution than merely following the law.
Google is dependant on Intel CPUs at the moment and has a vested interest in not saying well our cloud just got 5-30% percent slower.
Exactly the same as their competitors, including in-house data centers as well as other cloud providers.
Spectre is a red herring - there is no known way it can be exploited.
Yet.
non-Intel users have not been compromised
So far.
Frankly, this whole hoopla about Spectre seems like a well orchestrated deflection stunt by Intel PR operations. And your posts smells a bit of sockpuppetry.
Intel had nothing to do with it; all three issues were found by Google Project Zero (who didn't name them; GPZ doesn't do silly vulnerability marketing games), and then independently by other researchers.
Note that I'm not trying to defend Intel. I'm an AMD fanboy from way back, and I'd love to see this give AMD a major boost in sales for a few years. But let's not get overconfident. This is a brand new class of attack and few security researchers have focused on it yet. There will be more attacks.
Note that the attack does allow code to spy on memory in the same process on AMD. This seems at first glance to be a non-issue... until you consider that lots of processes -- like your web browser -- run JITed code from untrusted sources. Malicious Javascript able to read any data from the browser process is a big deal. Even if your browser uses a separate process per tab, this means that resources on a page can break the same origin policy. With Chrome you can optionally enable strict site isolation which will run the content from every origin in a different process, but that comes at a performance cost.
I leased my Nissan Leaf as well, until I bought it. In 2016 my lease was expiring and I extended for a year. In 2017 it expired and I bought the car.
This all worked out to be *extremely* economical, mostly because Nissan badly mis-estimated the resale value. I leased a $35K vehicle for ~$210 per month for 36 months (no cash down, though there were some documentation fees and sales tax that had to be paid up front on the $7500 federal tax credit). When the lease ended, I paid $6000 to buy the car. 36 * 210 + 6000 = 13,560. Oh, and my total maintenance expenses have been one set of replacement tires, ~$200.
As for battery life: I have 60K miles on the car and haven't lost more than about 10% of my range. The battery capacity degradation curve is steepest early on, so I expect the car to have >80% of its range basically forever.
I have $1K down on a Model 3. I'll probably lease it as well, since I don't think the EV technology progress curve has flattened out significantly yet.
- on Intel CPU, you have a violation of boundary separation : an end-user application could access information leaking out of the kernel.
- on AMD CPU, this does not happen : you only access information on the same side of the separation boundary.
All of the people saying "Ha! Intel only! AMD is better!" are missing the point. The concern isn't only about the specific attacks devised so far. The concern is that we have a whole new class of attack, exploiting a fundamental feature of the architecture of all modern CPUs. Yes, AMD is less vulnerable to the attacks so far devised, but that is an accident. AMD didn't design to protect against this class of attack, because they didn't know about it.
As Bruce Schneier likes to say: Attacks always get better. It's not at all unlikely that new variants that AMD is vulnerable to will be found, including some that perhaps Intel is not.
Until we revisit CPU design and take steps to ensure that cache changes made by one process can't be detected by another process, there will be a series of ever-more-clever attacks devised that exploit this hardware side channel.
OTOH, part of me is an old AMD fanboy, going back decades, and would love to see this give AMD a big boost. If the required mitigations on Intel are as damaging to performance as some tests indicate, AMD could find itself as the performance champion again. I don't think it looks like that's going to happen based on the current exploits, but I can hope ;-)
If you're sharing hardware with an unknown number of other tenants and have free reign on your VM, yeah this is a huge security hole.
Or running code you download from the web.
As far as web-servers using java script to read your kernel mode memory... yeah, not good, but then if you're visiting a illegitimate website you don't trust, you probably should be in a sandboxed VM anyway. Evil sites are evil.
Good sites can also be evil. If your connection isn't secured, any hop between you and the server can feed you malicious code. If the server isn't well-secured, it can be hacked to send you malicious code. If the server developers just get a bad version of a legitimate library, it can send you malicious code. And so on.
This makes VMs a bit less bulletproof.
A lot less. Given the right gadget in the hypervisor, this could be used to read hypervisor memory.
It's not the end of the world. The attacks aren't terribly easy to mount, and we can apply mitigations to make them even harder. But remember... this is just the first step. This is an entirely new class of side-channel attacks, so the initial vulns are just the beginning. More is coming.
Ultimately, we need new CPUs that have per-ring caches, or swap caches on privilege level context switch, or perhaps unwind cache state when they unwind a pruned speculative execution path. But this class of vulnerability is a new one that security engineers are going to have to guard against in software until hardware fixes are available, and we don't yet fully understand the implications.
It's about upselling.
Sort of, but not exactly. It's about having a product in every price point. The value of a robot vacuum is not the same to every person, both because some get more value from it, and because some value money less. The Laffer curve says that to maximize profit with a single product you lower the price until the marginal increase in profit due to volume matches the marginal decrease in profit due to lower sale price. But if you do that, you're leaving money on the table because a lot of people would have been willing to pay more.
The fix is to have a range of products at different price points. To some extent you do this by making versions of varying quality, so the higher-priced units cost more to make and are better (but still have roughly the same profit margin, which means more actual profit for the higher-end versions). But there's a limit to how much real differentiation you can make. The solution is to introduce lots of small feature differences, including deliberately disabling features on some models. Buyers will almost always get the most expensive model they can afford, or maybe just one step down, as long as there is some difference that they think they might like to have.
The most, er, interesting examples of this are when companies sell the exact same product at different price points. A factory may put two different logos on the same product and sell them at different prices, for example. IBM was famous back in the day for selling "single-CPU" mainframes that were actually delivered with four CPUs on board. If you wanted to upgrade your computer and make it faster, they sent a guy out to turn on some more cores in exchange for a hefty fee. Or later, they turned them on for you remotely. And if your check bounced they turned them right back off.
Coupons and other sorts of discounts are another tactic. You can set the normal price high but occasionally sell it for less via some mechanism that is just complicated or difficult enough that those who can afford the higher price won't bother.
Depending on your perspective, these shenanigans are either cheating or giving the customer what they want at the price they want to pay.
Of course, mass personalization may mean that companies don't have to do this so much any more. Rather than having a half-dozen different products at different price points, they can make only one... but based on knowing who you are they can offer you the highest price you're willing to pay.
Financially, the calculus is even worse
Only if you want to drive a used car. If you're going to buy a new car either way, and your driving patterns fit the profile that current EVs work well for (which is becoming less of an issue; 200+ miles range works for most people), then the total cost of ownership calculation for EVs gets to be pretty good even without tax credits, and quite compelling with them.
And if you don't mind driving a used car, you can buy a used EV. It's pretty disingenuous of you to compare new EVs to used ICEVs.
It's not immediately clear exactly why Google is building a new operating system...
Possibly to un-encumber themselves from the GPL? I note that Fuchsia's licenses are a mix of MIT, BSD, and Apache. This would potentially allow them to adapt the OS to just about any environment without having to release the source code.
Note that those are the same FOSS licenses Google uses on all of its open source projects. I wouldn't read anything into those choices.
Other than GPL isn’t one of them?
Right, GPL isn't one of them. The point is that the same licenses are used by Google on lots of stuff, for which they don't hold back source code, so there's no reason to assume that the same choice of licenses indicate that Google is planning on holding back source in this case.
For that matter, they could use the GPL without losing the ability to hold back source when they want to. The owner of GPL'd code is not required to abide by the terms of the GPL. That only applies to other people who want to use it. In many cases, even the original author is eventually constrained because of third party contributions which they don't own or have any license to other than the GPL. But Google isn't accepting third party contributions now and even if they were to do so in the future the standard Google open source contributor agreement requires that contributors grant Google an unlimited license to do anything at all with the code, so that wouldn't restrict what Google can do either.
In Canada, there's a crack down on some small business abuse that gives way more advantages over salary workers.
Yes, governments have to be careful to ensure that businesses aren't covering employee (or owner) expenses while claiming them as business expenses. The US IRS is quite good at this.
It works on the AMD and ARM cpu within the same process, without crossing any privilege boundaries.
Privilege boundaries can also be crossed with ARM CPUs, though it requires that the BPF JIT be enabled in the kernel.
This bug is epic.
Indeed. This is the only case I know of where Project Zero delayed beyond their 90-day disclosure window. They gave people six months to patch this time, because there was just so much to be done by so many organizations.
If someone can run a particular pattern of code on your system, all mapped memory is readable to them.
Not quite that epic. If someone can run a particular pattern of code on your system, all mapped memory accessible to the process in which the particular pattern of code is run is readable to them. If they can make it happen in, say, the OS kernel, of course, which has access to everything... that's pretty epic.
Based on other comments above, there is a fair chance you misunderstand the nature of the bug. It is reported that AMD validates requests for speculative execution before executing them, and Intel validates them afterwards. The bug is supposedly that it's possible to read the results of the speculative execution before the Intel chip notices that they were improperly executed. If that is so, then the AMD chips do *not* have this particular bug.
Look at the blog post I linked.
And low and behold, that's often what has happened
Aside: you may (or may not) be interested to know that the phrase is "lo and behold". The "lo" isn't about the height of something, it's an exclamation or interjection from Middle English, likely a shortened form of "look" (which was pronounced more like "loke"). So "lo and behold" means "look and see".