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

451–460 of 476 posts

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

#451

Post by Reelin »

waheoo wrote: post #439
Reelin wrote: post #409

Earlier quoted context omitted.

> because CRC is actually worse for checking file content collisions So use SHA-1 or SHA-2 or SHA-3 or if you really hate NIST standards for some reason then CubeHash or Skein or Blake2 or ...

Are you seriously suggesting sha-1 as a good replacement to md5... for security reasons?

Ahh poop, looks like I was out of date. Apparently a practical demonstration of an attack with complexity ~2^60 was recently demonstrated against legacy GPG (the v1.4 defaults) for less than $50k USD. [1] That being said, it looks like it still required ~2 months and ~900 GPUs versus MD5 at 2^18 (less than a second on a single commodity desktop processor).

So yeah, I agree, add SHA-1 to the list of algorithms to reflexively avoid for any and all purposes unless you have a _really_ good reason to use it.

[1] https://www.schneier.com/blog/archives/2020/01/new_sha-1_att...

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

#452

Post by nine_k »

pantalaimon wrote: post #401
roydivision wrote: post #345

Earlier quoted context omitted.

There are legitimate use cases for anti virus on Linux, for instance when running mail or file servers.

Aren't those scanning for Windows Viruses?

Some can be cross-platform JS exploits.

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

#453

Post by Reelin »

skissane wrote: post #446
Reelin wrote: post #409

Earlier quoted context omitted.

> because CRC is actually worse for checking file content collisions So use SHA-1 or SHA-2 or SHA-3 or if you really hate NIST standards for some reason then CubeHash or Skein or Blake2 or ...

The reason why CRC32C was chosen as a replacement instead of SHA-2 or whatever - what happens if in a few more years, SHA-2 isn’t considered secure any more and some future security audit demands it be changed again? Whereas, a CRC algorithm isn’t usually used for security purposes, so a security audit is far less likely to pay any attention to it. The whole issue started because a security-related technology was use…

> what happens if in a few more years, SHA-2 isn’t considered secure any more and some future security audit demands it be changed again

Then change it again? If you use the most recent available NIST standard it should hopefully be a very long time before meaningful (let alone practical) attacks materialize (if ever). If you end up needing to worry about that in a security audit, consider it a badge of success that your software is still in active use after so many years.

Using an insecure hashing algorithm without a clear and direct need is a bad idea. It introduces the potential for future security problems if the function or resultant hash value is ever used in some unforeseen way by someone who doesn't know better or doesn't think to check. Unless the efficiency gains are truly warranted (ex a hash map implementation, high throughput integrity checking, etc) it's just not worth it.

> a security-related technology was used for a non-security purpose

I would suggest treating all integrity checks as security-related by default since they have a tendency to end up being used that way. (Plus crypto libraries are readily available, free, well tested, generally prioritize stability, and are often highly optimized for the intended domain. Why would you want to avoid such code?)

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

#454

Post by scruffyherder »

stefan_ wrote: post #38
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.

Your company's antivirus, or GMail . A binary? A zip with a binary? Nuh-uh.

I use vmdk’s

Seriously I don’t know how long it’ll last but a zip file into a fat32 disk image in a vmdk got through just fine.

The bonus is that 7zip can extract from vmdk.

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

#455

Post by drudru11 »

msbarnett wrote: post #72
dosshell wrote: post #65

Earlier quoted context omitted.

Which country laws does apply? Is it really illegal to share this in the whole world? Im not so sure about that.

>Which country laws does apply? At the very least, Intel owns the copyright on this material, so sharing it is a copyright violation in any country that is a signatory to the Berne Convention or the TRIPS Agreement, which is effectively almost the entire planet. Then you have to add Trade Secret laws on top of that, which will have slightly narrower jurisdiction but still impact a lot of countries. There are very few…

Hi msbarnett: sorry unrelated to this thread. In an older thread you mention an acronym TFA. The thread was a discussion on sparse files and removing bytes from the front of a file. What is TFA?

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

#456

Post by ummonk »

ddingus wrote: post #432
ddingus wrote: post #316

Earlier quoted context omitted.

This is more like leaving it on the street, mixed in with a lot of other free stuff. Physical analogies break down. Truth is, this info was out there for anyone to copy, and who ever did that is definitely guilty of something and or liable. It will be tough to make passers by into criminals here. They aren't. Keeping secrets is hard. Should be.

I wrote this poorly. Meant whomever left this data in the clear is guilty of something and or liable.

It would be like keeping a dropped wallet - the person who keeps it is guilty, not the person who accidentally dropped it.

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

#457

Post by skissane »

dx034 wrote: post #370
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.

I actually think that's valid. Sure, http on a dev machine isn't a security risk. But there is a tail risk that it ends up somewhere on a system that sends data between machines. Also, using http on dev and https on prod can lead to unexpected bugs. Banning http is not unreasonable. Same with the md5 complaint. That use of md5 wasn't a problem but there's a perfectly fine alternative and if you can ensure by automate…

> and if you can ensure by automated tests that md5 is used nowhere

You can automatically check for the string "md5" in identifiers, but you can't reliably automatically check for implementations of the MD5 algorithm. All it takes is for someone to copy-paste an implementation of MD5 and rename it to "MyChecksumAlgorithm" and suddenly very few (if any) security scanning tools are going to be smart enough to find it.

(Foolproof detection of what algorithms a program contains is equivalent to the halting problem and hence undecidable, although as with every other undecidable problem, there can exist fallible algorithms capable of solving some instances but not others.)

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

#458

Post by RealityVoid »

spijdar wrote: post #177
netsec_burn wrote: post #152

Earlier quoted context omitted.

Or buy a laptop from a manufacturer with the ME inoperable.

The entire ME can't "technically" be disabled on modern Intel silicon. It's essentially the processor that "bootstraps" the whole CPU. Without (cryptographically signed) code running on the ME, the system can never boot. All the non-necessary bits can be disabled out of the box, however.

My understanding is that the DOD has access to machines with ME disabled. What is the capability that is disabled there, I wonder and how is that different than ME cleaner? Are they doing basically the same thing?

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

#459

Post by CapricornNoble »

kps wrote: post #281
dandare wrote: post #258

Earlier quoted context omitted.

A company I know insists on rotating passwords fairly often. Everybody just increases the number at the end of their favourite password, i. e. intel1255

I once worked at a place that required passwords to be changed every month and contain at least one upper and lower case letter, digit, and punctuation, and not match any previous password. So the password for August, 2020 would be “August, 2020”.

Many DoD websites are the same. It's so annoying. I use a password manager at home but at work I don't have that luxury (installable software is tightly controlled and very limited).

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

#460

Post by wmf »

RealityVoid wrote: post #458
spijdar wrote: post #177

Earlier quoted context omitted.

The entire ME can't "technically" be disabled on modern Intel silicon. It's essentially the processor that "bootstraps" the whole CPU. Without (cryptographically signed) code running on the ME, the system can never boot. All the non-necessary bits can be disabled out of the box, however.

My understanding is that the DOD has access to machines with ME disabled. What is the capability that is disabled there, I wonder and how is that different than ME cleaner? Are they doing basically the same thing?

Yes, they seem to be very similar. https://github.com/corna/me_cleaner/wiki/HAP-AltMeDisable-bi...
Post reply on HN