Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

20GB leak of Intel data: whole Git repositories, dev tools, backdoor mentions

twitter.com

Post reply on HN
Print view View original

261–270 of 476 posts

Re: 20GB leak of Intel data: whole Git repositories, dev tools, backdoor mentions

#261

Post by nullc »

noja wrote: post #85
wmf wrote: post #41

Earlier quoted context omitted.

AFAIK the ME is required to initialize the processor so it can never be completely disabled. The best you could do is remove any code beyond necessary initialization which has mostly already been done by me_cleaner.

How easy is it to use me_cleaner? Last time I looked it required some wiring and a Raspberry Pi.

On some devices it's fairly easy: pop the chip out (or attack to it in-circuit with a clip), drop it in a programmer, run a tool.. run me cleaner.. run a tool again.

On other devices you just can't read the chip or you can and me cleaner can't make any sense of it.

Re: 20GB leak of Intel data: whole Git repositories, dev tools, backdoor mentions

#262

Post by dcow »

MauranKilom wrote: post #256
dcow wrote: post #198

Earlier quoted context omitted.

I don't believe this is accurate or in any way obvious even if this is the stance the courts would ultimately take. These files were downloaded from a publicly available CDN server discovered while browsing the internet. No authorization mechanisms were bypassed, no computer systems were hacked. These files are the result of a GET request to an Akamai server that happened to be hosting the files. Despite how this wil…

You have a lot of faith in how technically versed the law and courts are on these topics - because they sure haven't kept up with the times. And even if they were willing to split hairs over these technical details: No civilian will agree with you that just because technically you could slip through several doors that happened to be not locked and got helpful advice from a neighbor, it doesn't mean that whatever you…

This isn't slipping through various open doors. There were no doors. This is literally a public server on the public internet serving files publicly. Intel is grossly negligent in securing their assets if they're hosting what they consider to be confidential trade secrets on public CDN servers.

The analog would be if I posted a flyer on a telephone pole with what I considered confidential information and someone else took a picture of it. There's no way you could argue that I had a reasonable expectation that only people for whom the flyer was intended would be able to view the flyer.

If someone deliberately bypassed computer security measures to acquire this information I'd agree. But you don't get a free pass to be negligent just because you're a big company. I suspect the EFF would support my viewpoint as they supported Weeve's appeal of a much more contentions and ethically gray scenario (the acquisition of personal information from a server that was negligently "secured" and required someone to imitate the calls an iPad would make).

Re: 20GB leak of Intel data: whole Git repositories, dev tools, backdoor mentions

#263

Post by nvr219 »

fastball wrote: post #150
crdrost wrote: post #139

Earlier quoted context omitted.

Because until this thing gets diffused and dissected by everyone and their mothers, the law is likely to view it as publication of confidential trade secrets, and people who can be confirmed to be spreading such things can get federal time, e.g. [1] for example. Using a VPN is the barest of mechanisms to try to obscure your identity to avoid this sort of punishment. [1] https://www.wsj.com/articles/SB1000142405297020…

Right but if you just download without seeding, no crime is being committed, yes? So seems like the barest you can do is "disable seeding", not "use a VPN".

Ahem. Not seeding is a crime.

Re: 20GB leak of Intel data: whole Git repositories, dev tools, backdoor mentions

#264

Post by [deleted] »

greedo wrote: post #215
restingrobot wrote: post #179

Earlier quoted context omitted.

So much this. My company just got done shelling out a ton of money for some asshat to tell me that we can't use http on a dev server.

It's worse when the asshat convinces your manager that every internal site, whether dev or not needs https. Certs everywhere. Our team spends a decent % of our time generating and managing certs...

[deleted]

Re: 20GB leak of Intel data: whole Git repositories, dev tools, backdoor mentions

#265

Post by TheSpiceIsLife »

marcosdumay wrote: post #36
pjc50 wrote: post #21

Earlier quoted context omitted.

Yes - but not for hostile purposes, but because your own company's antivirus won't let you mail an executable to a colleague.

Usually this. Or in my workplace, an image. Antivirus are some crazy shit that may trigger on any random action and will teach people to follow the most unsafe procedures without questioning, so they can get anything done.

Let’s call a spade a spade.

Antivirus software is malware.

Re: 20GB leak of Intel data: whole Git repositories, dev tools, backdoor mentions

#267

Post by meshaneian »

the8472 wrote: post #183
jopsen wrote: post #171

Earlier quoted context omitted.

Makes perfect sense. Defense in depth, if you can grep the source code and not find any references to md5, then you have quickly verified that the code probably doesn't use md5. This you can easily verify again later, you can even make a test for it :) Even if in practice this had no impact, removing md5 usage, will make it harder to accidentally introduce it in the future.

The issue is not md5. The issue one wants to detect is weak hash functions used in cases where they're not appropriate. The fact that crc32 passed means that any obscure hash function would have passed too, even if it had been used in a context were it isn't appropriate. All it means that the audit is superficial and doesn't catch the error category, just famous examples within that category. That kind of superficial…

Next up: Replace MD5 with BASE64+ROT13. Significantly worse functionality AND performance, but sounds more secure (to a layman) and doesn't trigger the "MD5" alert...

Re: 20GB leak of Intel data: whole Git repositories, dev tools, backdoor mentions

#268

Post by AlotOfReading »

sjg007 wrote: post #188
marcosdumay wrote: post #36

Earlier quoted context omitted.

Usually this. Or in my workplace, an image. Antivirus are some crazy shit that may trigger on any random action and will teach people to follow the most unsafe procedures without questioning, so they can get anything done.

Antiviruses will quarantine compiler output...

At one company, Symantec would also quarantine the compiler and build system. It certainly made builds exciting to have the antivirus playing Russian roulette with the entire toolchain.

Re: 20GB leak of Intel data: whole Git repositories, dev tools, backdoor mentions

#269

Post by mhh__ »

Keyframe wrote: post #96

At this rate, I fully expect Nvidia to make a meger bid for intel.

Bigger market cap but something like 10 times less revenue, strange world (As intel get hammered in the media their revenue remains in a different league to AMD - which I suspect is partly because AMD can walk the walk after dropping their trousers but there is no foreplay [i.e. sales and software])

Re: 20GB leak of Intel data: whole Git repositories, dev tools, backdoor mentions

#270

Post by zeroimpl »

dcow wrote: post #260
zeroimpl wrote: post #254

Earlier quoted context omitted.

That’s a very weak argument. If I’m walking down the street at night and somebody comes up to me and says “GET /money”, I may respond with an HTTP 200, but that doesn’t mean the person didn’t just steal from me.

You just gave them money. They didn't coerce you. It would be different if they flashed a weapon.

It's a fictitious example. I didn't say there was no weapon, nor said it was definitely theft. The point is that submitting a GET request in a public setting does not mean no crime.

Coercion can be the difference between asking for money and theft. In the case of this intel data, it was clearly coerced from a server - it's not like it was linked on Google, they had to specially craft URLs to coerce the data out.

Post reply on HN