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

101–110 of 476 posts

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

#101

Post by orisho »

yjftsjthsd-h wrote: post #98
jdminhbg wrote: post #69

Earlier quoted context omitted.

I think the difference is whether it's something that's always enabled. You could presumably make it available or not at compile time, so the software shipped to a customer wouldn't have it, but maybe if they were having issues, you could ship them a version with the debug server with their permission.

I can agree with that with the caveat that "enabled" has to be at either something that only the user can do. If it requires that the customer intentionally run a debug build, that's fine; if it can be toggled on without their knowledge, then it's a problem.

It was disabled by default, and could only be enabled using environment variables. Even when enabled, the whole thing ran in Docker and the socket was bound to loopback, so you could only connect to it from within the container.

When the intention is a debugging server, making it exposed to the world is a mistake and a security vulnerability. At that point it is effectively a backdoor, but the difference between a high level vulnerability such as this and a backdoor is developer intent.

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

#102

Post by alsdkfjkqjwer »

Why would they include stuff from proprietary releases?

I understand exposing backdoors and all, but who cares about a camera firmware for a airgaped system?

wonder if some of the clients for those devices is involved and the goal of this is that those clients got fed up with the NDAs and wanted all this in "public domain"?

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

#103

Post by neltnerb »

saagarjha wrote: post #64
somehnguy wrote: post #43

Earlier quoted context omitted.

Yes. Whenever I email or transfer a zip via any method really I always put a basic password on it. I've been bitten way too many times by dumb filters that pick some file out of the zip and declare that it is malicious. I also don't trust messenger apps to not pull my files out and do who knows what with them. A basic password prevents this junk 99% of the time for almost no effort. It won't stop a determined system…

Gmail doesn't seem to like archives it can't open :/

Ah, the halcyon days of merely changing the file extension from .exe to .txt...

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

#104

Post by akira2501 »

myself248 wrote: post #97
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.

I've heard it put this way: If you force users to trade convenience for security, they will find a way to obtain convenience at the expense of security.

> If you force users to trade convenience for security

I _wish_ it was better security they were making the trade for. It often isn't though. These programs are large, expensive, and don't do much most of the time. I feel there's a perverse incentive for developers to make their AV products as noisy as is possible to justify their own existence.

And yet.. even with full AV rollouts locked down at the highest level, bad actors still get into networks and exploit them. So, to me it feels like our users are trading away their convenience for our misguided CYA policies.

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

#105

Post by newacct583 »

yelloworangefog wrote: post #73
orisho wrote: post #11

At a previous workplace we had a few places in the code which used the word backdoor. It was not an actual backdoor though, but merely a debugging server that could be enabled and allowed you to inspect internal state during runtime. At some point I removed the word backdoor, fearing it would get to a customer or during an audit someone would misunderstand. :|

Frankly I don't think Intel's track record affords them the privilege of having good faith be assumed with something like this.

Intel doesn't have a track record of shipping back doors, or even "bad faith" software really.

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

#106

Post by pizza »

kmeisthax wrote: post #61
gabcoh wrote: post #28

Earlier quoted context omitted.

Is the person publishing this liable or just their source? Because this seems to be a hobby for the person publishing it and yet they also aren't concealing their identity. They list their former employer on their website.

Misappropriating trade secrets for financial gain is a punishable offense, and this data would qualify as a trade secret, at least for as long as it's not general knowledge to everyone or it has yet to be reverse-engineered. Aside from that, much of the data in these files has standard copyright and patent concerns.

OK then, out of curiosity, what are the relevant laws being broken here?

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

#107

Post by throwaway889900 »

johnklos wrote: post #42
svnpenn wrote: post #14

Someone have a mirror? Seems the actual files are here: https://t.me/exconfidential/590 Edit: files are here https://mega.nz/folder/CV91XLBZ#CPSDW-8EWetV7hGhgGd8GQ or magnet:?xt=urn:btih:38f947ceadf06e6d3ffc2b37b807d7ef80b57f21

You can't download from mega.nz unless you have their "downloader" app or an account, or if you have Firefox or Safari. It's useless. The torrent works.

JDownloader 2 works fine and goes around their limitations to boot.

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

#108

Post by oneplane »

eli wrote: post #93
dogma1138 wrote: post #88

Earlier quoted context omitted.

Fine personhole it is.

"Maintenance Hole" actually, which is better because it's both more descriptive and not gendered.

But what if manhole is just mankind hole? (It probably isn't, I didn't look it up). Man doesn't always mean male, or does it?

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

#109

Post by fit2rule »

yjftsjthsd-h wrote: post #52
orisho wrote: post #11

At a previous workplace we had a few places in the code which used the word backdoor. It was not an actual backdoor though, but merely a debugging server that could be enabled and allowed you to inspect internal state during runtime. At some point I removed the word backdoor, fearing it would get to a customer or during an audit someone would misunderstand. :|

It seems like a thin line between a debugging feature and a backdoor; "merely a debugging server that could be enabled and allowed you to inspect internal state during runtime" seems like a backdoor to me, doubly so if it's network-accessible. If Intel has, say, an undocumented way to trigger a debug mode that lets you read memory and bypass restrictions (ex. read kernel memory from user mode, or read SGX memory), is…

Was it a backdoor, or a hidden door, or .. a utility panel?

The difference, in my opinion, is in the documentation and frequency of use. Is it overt? Does the customer really know its there, and what its for?

Perfectly fine to have an access panel that gives you access to the buss .. if the pilot knows you're doing it.

But if its some random entrance in the back of an alley, only 2 or 3 users in the universe know what it is and how to use it ..

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

#110

Post by jnwatson »

danw1979 wrote: post #6

The advice to try a password of “Intel123” on any protected files says it all. This organisation genuinely deserves whatever is coming for them.

The primary use case for such passwords is not confidentiality. It is to bypass overzealous email virus checkers.
Post reply on HN