Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reflections on Distrusting xz

joeyh.name

Post reply on HN
Print view View original

321–330 of 335 posts

Re: Reflections on Distrusting xz

#321

Post by Calzifer »

justinsaccount wrote: post #211
loftsy wrote: post #86

I took a look at the diff linked in the article with code that "we are all running". The top of the diff certainly looks interesting. They remove the bounds check in dict_put() and add a safe version dict_put_safe(). This kind of change is difficult to make without mistakes because it silently changes the assumptions made when code calling dict_put() was originally written. ALL call sites would need to be audited to…

Also because the 'safe' version only checks dict->pos == dict->limit and not dict->pos >= dict->limit if you can get one call of dict_put somewhere to pass the limit, all later calls of dict_put_safe will happily overwrite memory and not actually be safe.

No, because dict_put will update the limit value if the new pos exceed it.

Re: Reflections on Distrusting xz

#322

Post by The_Colonel »

fl7305 wrote: post #281
The_Colonel wrote: post #258

Earlier quoted context omitted.

That relies on some heuristics which can be worked around, unless you disallow rewriting history. But the bigger issue is that this is some theoretical system which is not present in most git repositories.

The heuristic would be "sound the alarm if the main branch is rewritten". And maybe also "if a release tag that we have used for our distro is moved". Wouldn't that catch most problems, and not generate too many false alarms?

You can rename/switch branches. You can change what branch is considered main/master. You can find valid reasons why you'd want to do stuff which raises the alarms so that other people become deaf to them, and only then execute the rewriting attack. Relying on people noticing (even with alarms) is just super fragile.

Re: Reflections on Distrusting xz

#323

Post by fl7305 »

The_Colonel wrote: post #322
fl7305 wrote: post #281

Earlier quoted context omitted.

The heuristic would be "sound the alarm if the main branch is rewritten". And maybe also "if a release tag that we have used for our distro is moved". Wouldn't that catch most problems, and not generate too many false alarms?

You can rename/switch branches. You can change what branch is considered main/master. You can find valid reasons why you'd want to do stuff which raises the alarms so that other people become deaf to them, and only then execute the rewriting attack. Relying on people noticing (even with alarms) is just super fragile.

> You can rename/switch branches. You can change what branch is considered main/master.

Sure, in the project repo the branches are just simple text files that contain the hashes of the commits they point to.

So they are trivial to change in the project repo. But it is also trivial for the distro project to keep copies of the branch/tag info and check against those. I guess what you mainly care about are the previous release tags. They should never change after a release.

> Relying on people noticing (even with alarms) is just super fragile.

I'd say there's plenty of motivation now for the major distros to put infrastructure in place to automate this (keeping track of previous releases) and to actually keep looking at the alarms.

> You can find valid reasons why you'd want to do stuff which raises the alarms so that other people become deaf to them

I'm sure the attackers would try things like that.

But let's say you have an open source application/library that is part of Debian.

How common has it been in the past that the app/lib project had a bunch of tagged releases, and then wanted to rewrite the history so that the tagged releases now point to different commits? I assume it has been very uncommon, but maybe I'm wrong?

And even if that is the case, new infrastructure tools can keep local copies of the source code for previous releases, and check against that.

Repo checking is not trivial, perfect, or sufficient. But I'd say it's a necessary component in guarding against attacks.

The big challenge is still that there is so much code added/changed for each new release of apps/libs that it is very difficult to check against attacks. The obfuscated C contest has proven again and again how hard it is.

Re: Reflections on Distrusting xz

#324

Post by reisse »

brabel wrote: post #299
reisse wrote: post #61

Earlier quoted context omitted.

No-one working on open source code on their time owes anything to anyone using the code. If you want an important open source project to be maintaned by non-anonymous person, surprise-surprise, hire that person and pay them. Besides, some of the best open source contributors I know are almost-anonymous people behind nicknames and anime girls avatars.

It is not about owing someone... it's about having provenance of code. If you're just an anonymous guy doing stuff for free and want to remain anonymous, that's fine, but then your software shouldn't be used by anyone who cares about toolchain attacks as there's just no way to trust you, and no way to verify every single commit you make on new releases. For software that gets used by many, which is a goal of OSS (oth…

> If you're just an anonymous guy doing stuff for free and want to remain anonymous, that's fine, but then your software shouldn't be used by anyone who cares about toolchain attacks as there's just no way to trust you, and no way to verify every single commit you make on new releases.

What is, from security point of view, the difference between a toolchain attack performed by an anonymous contributor and by an identifiable real person?

> For software that gets used by many, which is a goal of OSS

It's not. The goal of OSS is to give users the possibility to study, change and improve the software. And that includes giving you ability to independently audit the code. All of that does not need any person behind it.

Re: Reflections on Distrusting xz

#325

Post by berniedurfee »

irdc wrote: post #8

One thing that comes to mind is that “Jia Tan” might be more accurately seen as a “sleeper” of some sort: a foot soldier who infiltrates a juicy open source project and waits for further instructions; backdooring sshd might not have been part of the original plan. Which raises the concerning question of how much more sleeper maintainers there are.

When you find one cockroach, you can be sure there are thousands more you haven’t found.

Re: Reflections on Distrusting xz

#326

Post by justinsaccount »

Calzifer wrote: post #321
justinsaccount wrote: post #211

Earlier quoted context omitted.

Also because the 'safe' version only checks dict->pos == dict->limit and not dict->pos >= dict->limit if you can get one call of dict_put somewhere to pass the limit, all later calls of dict_put_safe will happily overwrite memory and not actually be safe.

No, because dict_put will update the limit value if the new pos exceed it.

I don't see anything like what you are describing. What line exactly are you talking about?

Re: Reflections on Distrusting xz

#327

Post by mikrotikker »

lenerdenator wrote: post #264
irdc wrote: post #45

Earlier quoted context omitted.

“Given enough underfunded maintainers, all security is shallow.”[0] 0. https://en.wikipedia.org/wiki/Linus%27s_law

I wouldn't say "funding" is necessarily the problem. Most maintainers do it because they like doing it. Their main limiting factor is time. I can drop a million dollars an hour into a maintainer's lap; that doesn't mean they can dedicate every waking moment to a project. They still have human needs that money can't buy like sleep, family obligations, and health concerns. And that's making the assumption that the main…

We need to utilise a specialised AI to scan through the code looking for bugs and security holes. Imagine if openai donated server time to this.

Re: Reflections on Distrusting xz

#328

Post by berkes »

adql wrote: post #98
galangalalgol wrote: post #90

Earlier quoted context omitted.

Agreed, as a developer: minimize your dependencies while providing your core function. Don't grant dependencies permissions they don't need. Be granular about it. Austral lets you select what filesystem, network, etc. access each library gets. Also, in big organizations, risk assessment is more about making sure there is someone to point the finger at, than actual security. Treating libfubar as golden because it ship…

> Agreed, as a developer: minimize your dependencies while providing your core function. Don't grant dependencies permissions they don't need. Be granular about it. Austral lets you select what filesystem, network, etc. access each library gets. Still wouldn't help for this particular exploit.

In a way it would.

If a software project has hundreds of dependencies, finding that one that was compromised is hard, impossible even. But if it has three dependencies (that aide in the core functionality) keeping a keen eye on them is much easier.

When I look at a typical `node_modules` or `pipenv` directory, I see there's absolutely no way I can vet that all is safe in there. When I look at my typical cargo tree, the four or five dependencies (of dependencies) are doable to just go over every so often.

Automation helps. But that doesn't give me the confidence that just opening the project pages of the stuff that I use, once every few months does for me.

Re: Reflections on Distrusting xz

#329

Post by SanitaryThinkin »

xign wrote: post #314
SanitaryThinkin wrote: post #75

Earlier quoted context omitted.

On top of what you mentioned I also dislike the TSA-like response the OSS community is taking with this happen stance. I have anonomously contributed to many projects because I enjoy my privacy. All of my founding projects have also been done with anonymity. Because someone wants their anonmity and privacy does not mean they're nefarious, and I find it funny the group that takes to these principals most is negging on…

Personally, I do find it hard to trust an open source project maintained by an anonymous person. (I'm talking about maintainership, not regular contributions that need to be code reviewed by another maintainer) I may toy around with them but I will probably not use them in a manner where I need to trust them continuously. It's totally cool for you to do whatever you want, since it's a free world after all, but if you…

> You can do things anonymously, but big companies / projects also don't have an obligation to use your code.

You're not wrong here, but I'm not forcing anyone to use my code bases or contributions.

Also, think about how many systems you blindly trust on a daily basis.

When you drive over a bridge, did you research the maitenance procedures and compliance was up to date?

When you got a house or apartment, did you look into the engineering sign offs and construction companies? And that maitenance has been done up to snuff? Even down to hoping the inspector knows what they're doing?

When you step into an elevator do you check the recent inspection plaque?

When you get on an airplane are you aware of its maitenance history? And to further my point by refering back to the house example, did the company even QA the plane before they shipped it?

And most importantly, did you check into whether the people actually did these things versus just saying they did them?

What kind of trust does having a persons name attached to the project actually provide? I would argue its a psuedo-facade trust basis that gives a false sense of security.

The truth of the matter is that you blindly trust millions of things on a daily basis. Including the very system you type from, which I guaruntee you has more than one anonymous maitainer attached to its underlying software.

I totally get where you're coming from, but the same problems exist in every industry, supply, politics, every facet of your life is based on many blind trust principles.

The one difference here with anonymous open source contributors is that they give you the code to read through yourself (and hope that you help ;) )

Very much unlike the proprietary software you're running beside it.

Re: Reflections on Distrusting xz

#330

Post by pants2 »

moritonal wrote: post #74
constantcrying wrote: post #62

Earlier quoted context omitted.

>Which raises the concerning question of how much more sleeper maintainers there are. Given how easy the infiltration is and how extremely hard to detect it is, likely a lot. For an intelligence operation it is also extremely cheap, you just need a few knowledgeable developers spending some time each week on the project. The upside being a backdoor into a significant portion of infrastructure, the downside being wast…

The irony is that this would make a oddly effective way of having paid open source devs who for the most part just honestly improve projects. With the massive downside they undermine it at a critical moment.

The ideal situation is having multiple intelligence agencies all working on one project and spotting each others' backdoors, so at the end of the day we just have a really secure and well-maintained project.
Post reply on HN