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

441–450 of 476 posts

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

#441

Post by waheoo »

reallydontask wrote: post #340
andreareina wrote: post #301

Earlier quoted context omitted.

Not hard to win if everyone is being reasonable. Given an auditor that thinks all uses of MD5 are proscribed, what would you put the odds of them being reasonable at? ETA: per 'kbenson it's not hard to conceive of a situation where proscribing MD5 is reasonable. Taking 'skissane's account at face value is probably reasonable, but my implicit assumption that the auditor would not explain if pressed isn't being charita…

indeed Specially with the audit/pen test theatre where they have to put something in the report, otherwise why are they getting paid £20K for two days work? So most people choose the past of least resistance, when it doesn't matter much, so that you fight where it does.

Picking your battles is something we all need to learn to do.

I for one like to pick the easy wins, like this.

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

#442

Post by kbenson »

waheoo wrote: post #438
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…

What is this weird incessant need to play devils advocate. Sometimes people are just right.

Because most times people aren't "just right", they're just unwilling to widen their point of view, and/or they turn the issue into a way to assert their own importance and intellect over someone else at the expense of those they work with.

I don't need some coworker getting into some drawn out battle about how MD5 is fine to use when we can just use SHA (or CRC32C as that person did, which is more obviously non-useful for security contexts) and be done in 30 minutes. The auditor is there to do their job, and if what they request is not extremely invasive or problematic for the project, implementing those suggestions is your job, and arguing over pointless things in your job is not a sign of something I want in a coworker or someone I manage.

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

#443

Post by getoffmyawn »

mafriese wrote: post #400
getoffmyawn wrote: post #380

Earlier quoted context omitted.

well in any case thanks for FUDge-packing this discussion and sharing your opinion which is based on nothing. i'll make sure to credit you as my partner-in-crime after I get my door kicked in for downloading files on the internet.

I notice that you have no one in your circle of acquaintances who has illegally downloaded movies about torrents and got caught. I don't know how it is in other countries, but here in Germany friendly people ring your doorbell and take everything that is connected to electricity :). And if there is any data in there that is very damaging to Intel, then I think they will take the trouble to look for these people (at l…

i'm sorry you live in a hellhole country and your friends don't understand how bittorrent works. maybe one day you can immigrate to a second-world country and grow some cojones, but until then you should continue living in fear and scaring your peers from downloading leaks early when there aren't fed trackers.

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

#444

Post by mzs »

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

indeed it literally was the author's suggestion to search for the word 'backdoor':

>This code, to us, appears to involve the handling of memory error detection and correction rather than a "backdoor" in the security sense. The IOH SR 17 probably refers to scratchpad register 17 in the I/O hub, part of Intel's chipsets, that is used by firmware code.

https://news.ycombinator.com/item?id=24084977

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

#445

Post by fakecigar »

majewsky wrote: post #423
akira2501 wrote: post #104

Earlier quoted context omitted.

> 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, b…

My guess/fear is that most AV software gets deployed because some insurance policy requires you to tick that box.

A lot of this stuff (AV software) is getting deployed at all different layers of the environment. Firewalls are getting better at dynamic file analysis and file blocking, the endpoints are loaded with user behavior/analytics, av and dlp tools. AV is so omnipresent because it's in a decent amount netsec appliances these companies stand up

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

#446

Post by skissane »

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

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 used for a non-security purpose.

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

#447

Post by wmf »

rasz wrote: post #328
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.

Afaik that stil leaves Computrace backdoor in the bios.

UEFI can also be "cleaned" in most cases.

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

#449

Post by skissane »

Spooky23 wrote: post #437
skissane wrote: post #399

Earlier quoted context omitted.

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 :)

> I was taken aback by the costs of this stuff, which made the Sun gear I worked with look extremely cheap :)

Given the shrinking market share of mainframes, the only way for vendors to continue to make money is to increase prices on those customers who remain – which, of course, gives them greater encouragement to migrate away, but for some customers the migration costs are going to be so high that it is still cheaper to pay megabucks to the mainframe vendor than do that migration. With emulated systems like the ones you saw, the high costs are not really for the hardware, they are for the mainframe emulation software, mainframe operating system, etc, but it is all sold together as a package.

At least IBM mainframes have a big enough history of popularity, that there are a lot of tools out there (and entire consulting businesses) to assist with porting IBM mainframe applications to more mainstream platforms. For the remaining non-IBM mainframe platforms (Unisys, Bull, Fujitsu, etc), a lot less tools and skilled warm bodies are available, which I imagine could make these platforms more expensive to migrate away from than IBM's.

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

#450

Post by meowface »

dcow wrote: post #364
dleslie wrote: post #293

Earlier quoted context omitted.

Not quite, it was vacated on the grounds of improper venue. It wasn't reversed or similar; to be vacated is to be voided, as though the case never occurred.

I mean yes. I wish it was actually reversed on grounds that the ruling didn't stand. But that was the intention of the appeal. Dismissing it on improper venue is simply tactical. This is the legal system's way of saying, "there was enough contention in this case that we don't feel comfortable with the whole thing in the first place so we'll throw it out on a technicality and avoid inventing any case law here".

I'm not a lawyer, but I'm not 100% sure if thats's the best interpretation. It being thrown out on a technicality doesn't necessarily imply anything about their feelings regarding the facts of the case.

Basically, I would not be surprised that if the exact same case happened today, the defendants would still get jail time.

Post reply on HN