Live data from Hacker News

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

twitter.com

91–100 of 476 posts

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

#91
post #85
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.

Quite straightforward, I used a ch341A SPI programmer. Just make sure you take multiple copies of your original ROM image and compare the hashes of them to make sure there was no screwup.

It took me about 10 minutes to do my ThinkPad. All I lost was some enhanced integrated GPU power management and integrated thermal management, but I use a userland fan control program anyhow.

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

#92
post #58
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. :|

We use the term “manhole” for those sorts of things

[deleted]

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

#93
post #80

Earlier quoted context omitted.

Yes, yes. Seems like an outdated term. Downvotes accepted.

Fine personhole it is.

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

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

#94
post #48

Earlier quoted context omitted.

> but some of that code might help Coreboot development Unlikely. Most projects won't come anywhere near this sort of thing. There may be a possibility of doing clean room implementation, but writing the spec based on stolen IP is the problematic step. Then again, there is a high chance that none of this will be useful.

It will be more or less impossible to prove or disprove that anyone obtained some crucial information from there. The info will always somehow make it's way into the places it's needed eventually.

It doesn’t matter if it’s provable or not, most developers won’t risk it especially if they want to keep their jobs or be hireable.

If you review the content and publish say a blog post, even without legal repercussions it can impact your ability to be hired in the future since everything you do from that point can be tainted.

So if you do look you should keep it quite or publish it under a pen name that you can’t ever take credit for.

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

#95
post #17

Earlier quoted context omitted.

Of course it's not legal. This is exfiltrated intellectual property being shared without license.

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

Copyright law is fairly universal, so while stealing data/info from another company may not be illegal (depending on jurisdiction) copyright laws are pretty universal.

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

#97
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.

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.

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

#98

Earlier quoted context omitted.

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…

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.

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

#99
post #48

Earlier quoted context omitted.

> but some of that code might help Coreboot development Unlikely. Most projects won't come anywhere near this sort of thing. There may be a possibility of doing clean room implementation, but writing the spec based on stolen IP is the problematic step. Then again, there is a high chance that none of this will be useful.

It will be more or less impossible to prove or disprove that anyone obtained some crucial information from there. The info will always somehow make it's way into the places it's needed eventually.

Maybe, but are you sure you want to end up in a very expensive court battle with Intel?

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

#100
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. :|

A manufacturer wanted to upgrade one of their equipment lines to be more modern. The developers of the original product, both hardware and software, were no longer with the company.

Since they just wanted to add some new features on top and present a better rack-based interface to the user, they decided to build a bigger box, put one of the old devices inside the box, then put a modern PC in there, and just link the two devices together with ethernet through an internal hub also connected to the backpanel port and call it a day.

The problem is, if you do an update, you need both the "front end" and the "back end" to coordinate their reboot. The vendor decided to fix this by adding a simple URL to the "backend" named: /backdoor/Reboot?UUID=

Their sales team was not happy when I showed them an automated tool in a few lines of ruby that scans the network for backend devices and then just constantly reboots them.

They still sell this product today. We did not buy one.

Post reply on HN