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

431–440 of 476 posts

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

#431

Post by quotemstr »

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

It does though. There's no excuse for unencrypted traffic. Google doesn't have some VPN with squishy unencrypted traffic inside. Everything is just HTTPS. If they can do it, so can you. It's just not that hard to manage a PKI.

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

#432

Post by ddingus »

ddingus wrote: post #316
ummonk wrote: post #290

Earlier quoted context omitted.

If someone leaves their door unlocked and open it doesn't mean I have a right to walk in and take what I want.

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.

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

#433

Post by kr99x »

als0 wrote: post #410

The FSP source code is supposedly leaked as part of this, which is used to initialise the memory controller. Are we closer to (modern) blob-free Intel platforms?

CloseR, yes. Close? No. For one, memory init code differs from product gen to product gen and pulls in platform/board specific libraries and inputs to set up some parameters. The bigger problem though is just how big and messy the memory init code is. It would take a substantial number of people a substantial amount of time to unwind and understand what's going on, let alone do a sane and/or clean-room implementation of it all.

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

#434

Post by kr99x »

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 number one (by a wide margin) reason for Intel123 is that somebody is trying to email a zip to somebody else, but a mandatory filter notices "bad files" (oh no, executables!) inside the zip and removes it to keep people "safe". So the zip gets a common, known password, and the recipient gets their files in peace. It's not a security measure at all. It's a workaround for braindead IT "solutions" hindering day-to-day operations. The files can be shared via any number non-encrypted channels just fine, but the particular employees trying to share happen to be most familiar with email and the filter doesn't know or care if there are secrets - there are EXECUTABLES! Those are dangerous, don't you know?

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

#435

Post by Nemo_bis »

hedora wrote: post #124
gabcoh wrote: post #16

Is releasing this legal? It seems like this person isn't really disguising their identity or concerned about breaking the law. In their profile they even seem to brag about leaking company's code.

Stealing it is probably illegal, and there’s a copyright and export regulations argument to be made around copying it. However, my understanding of the law is that, once secrets are made public, further distributing the secrets is not illegal. So, republishing it is probably not more illegal than running a torrent of a Hollywood movie and an Ubuntu ISO (which can run afoul of export regulations). Note: I’m not a lawy…

Also, there are currently hundreds of seeders (according to a popular torrent indexers) and there were probably thousands of snatches. Good luck prosecuting that many people.

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

#436

Post by kr99x »

The three "biggest deals" here are all... a lot less important than they look. Clarifying info on all three:

"Did Intel get hacked?" I can't confirm the exact mechanism by which these files got out, but I do know that these files are things which get shared externally already with Intel's customers under NDA. If security in general is lax, that's one thing and future hacks of more sensitive stuff could be expected. If security in general is fine, but for some NDA customer sharing channel is lax, don't expect to see anything juicier.

"Intel123 is an awful password." Yes it is, but... it's not for security. Intel123 is the password used to bypass executable/script filtering systems that overzealous IT put in place to "protect" employees. Employee A wants to share a zip with employee B. There are many channels they can use to do this, because the contents of the zip are not encrypted or restricted. None of these channels require encryption, but either A or B doesn't like/understand them, so they agree on email. Whoops, the filter says that executable could be harmful and out it goes. Zip-via-email doesn't work. Unless... well, if they put a password on it, the filter doesn't catch it. Good. Problem solved. This is so common that the convention Intel123 arose and solidified for exactly this purpose.

"I see the word 'backdoor' in there!" Sure. Bad name choice. That's not the kind of backdoor you're thinking. There are a lot of things in the firmware that take this exact same form and don't use the word backdoor. It's a signal the low level firmware is keeping an eye out for, and if received, it will trigger some other piece of firmware to do some task in SMM. If that other piece of code takes input parameters and fails to verify them, then you may have a vulnerability on your hands - in fact, this was a very common kind of vulnerability before. Intel has fixed a lot of these over the years. Odds are they're mostly gone by now. If input parameters are verified (or none taken), the worst you could do is maybe a DoS by spamming that signal to keep the CPU clogged/stuck in SMM.

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

#437

Post by Spooky23 »

skissane wrote: post #399
Spooky23 wrote: post #313

Earlier quoted context omitted.

I remember early in my career I came across a Unisys “mainframe”, which was literally a Dell box with a custom bezel, clustered with a few other nodes with a Netgear switch.

Many non-IBM mainframe vendors switched to software emulation on more mainstream platforms-nowadays mainly Linux or Windows on x86, but in the past SPARC and Itanium were also common choices. What you saw may have been an instance of that. A software emulator can often run legacy mainframe applications much faster than the hardware they were originally written for did. (With Unisys specifically, at one point they sti…

I don't know the details (~20 years ago), but pretty sure you hit the nail on the head. I think one of the boxes I saw were a hybrid -- Xeons with some sort of custom memory controller.

It was my first exposure to this sort of thing, and I was taken aback by the costs of this stuff, which made the Sun gear I worked with look extremely cheap :)

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

#438

Post by waheoo »

kbenson wrote: post #300
waheoo wrote: post #280

Earlier quoted context omitted.

I agree with your sentiment in general, but this is telling a dumbass where to go. Its not a hard argument to win. Md5 here is fine, its not a security check.

Sometimes the point isn't technical, but social. So MD5 isn't used for security purposes right now. At some point someone will want some hashing function, and they'll probably look at what the code already uses. The last thing you want is someone a bit clueless goi g "it was good enough there, it's good enough here" and using MD5 where they shouldn't. Removing it from a codebase helps with that problem. The problem h…

What is this weird incessant need to play devils advocate.

Sometimes people are just right.

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

#439

Post by waheoo »

Reelin wrote: post #409
hashhar wrote: post #407

Earlier quoted context omitted.

because CRC is actually worse for checking file content collisions (not that MD5 is perfect either).

> 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?

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

#440

Post by waheoo »

raverbashing wrote: post #341
kbenson wrote: post #300

Earlier quoted context omitted.

Sometimes the point isn't technical, but social. So MD5 isn't used for security purposes right now. At some point someone will want some hashing function, and they'll probably look at what the code already uses. The last thing you want is someone a bit clueless goi g "it was good enough there, it's good enough here" and using MD5 where they shouldn't. Removing it from a codebase helps with that problem. The problem h…

The reason they ask is that they have to fill a checkbox that says "no MD5" and of course they're don't know that CRC32 is worse And to be very fair, a lot of security issues would be caught with basic checkbox ticking. Are you using a salted password hashing function instead of storing passwords in plaintext? Are you using a firewall? Do you follow the principles of least privilege?

Except this is not for password hashing.

Why is this so difficult to grasp.

Post reply on HN