34 ms·
I'm glad I'm not the only one who thinks this. Clever parsing code, multiple commits to get it right (https://github.com/WayneD/rsync/commit/2f7c583143bc6e8090
by testplzignore 4y ago
I'm glad I'm not the only one who thinks this.
Clever parsing code, multiple commits to get it right (https://github.com/WayneD/rsync/commit/2f7c583143bc6e80902139c23d9d7283f88fbc6a https://github.com/WayneD/rsync/commit/2f7c583143bc6e8090213..., https://github.com/WayneD/rsync/commit/3d7015afa223494e3318495c2f5de9cb49229da9 https://github.com/WayneD/rsync/commit/3d7015afa223494e33184...), no tests, seemingly no code review. Not an attack on the maintainer of rsync - this pattern is typical for security patches.
Within a few days, tools like Twistlock are going to alert on the CVE, and companies across the world will blindly upgrade without reviewing the change. Rinse and repeat thousands of times per year.
Our industry continues to not take security seriously while pretending that it does.
- kbenson 4y agoMy guess (hope) is that orgs like Red Hat will vet it a bit before putting it out, since they'll have to dive into the code and apply or reimplements it for multiple past versions of rsync. That actually covers a lot of companies using it. Paying (or at least relying on) another company to take care of that for you is what most places do. Honestly, that's better than tens of thousands of people wasting time on the same thing IMO.
- fsflover 4y agoIf you care about security, you should not rely on a perfect code. Consider compartmentalization instead: https://qubes-os.org https://qubes-os.org. Works for me (or so I hope).
- nonrandomstring 4y agoAlso consider policy [1]. It's become a dirty word because it's been somewhat hijacked by management-class values and wrapped up in an unthinking "compliance and audits" mind-set. Thinking about what you want to allow, where to draw lines, planning in advance and sticking to it (including using tricks that force you to stick to it) is mature security thinking. You only have to be an organisation of one person to have a security policy. https://news.ycombinator.com/context?id=32248506 https://news.ycombinator.com/context?id=32248506
- forgetfulness 4y agoThat's of course on the side of due diligence on the user of any software, but most software should have tests, and certainly one of the importance of rsync, doubly so because it's written in C.
- trasz 4y agoTests aren’t particularly useful for detecting this kind of bugs though.
- eikenberry 4y agoYou add tests for this sort of thing after the fact to make sure the fix works as you think it does and to make sure the issue isn't re-introduced later. Tests can't find them, but they can help keep them away.
- codedokode 4y agoI don't like the architecture because it looks like a set of ugly hacks. You don't need virtual machines to isolate applications because CPU already has a sandbox provided by protected mode. The problem is that legacy OS like Linux/Mac/Windows are unable to use this sandbox effectively. For example, here [1] they show a separate VM for the USB stack. But why do you need it if you can simply run USB stack in protected mode? Also, I assume that running so many VMs requires a lot of drive space and hurts performance. [1] https://www.qubes-os.org/intro/ https://www.qubes-os.org/intro/
- fsflover 4y ago> I don't like the architecture because it looks like a set of ugly hacks. It's not a set of hacks. You simply isolate your workflows using a hardware virtualization, transparently to the user. > You don't need virtual machines to isolate applications because CPU already has a sandbox provided by protected mode. What exactly do you mean? Qubes uses VT-d hardware virtualization. AFAIK it's the most secure compartmentalization method, and you can't use it without VMs. > But why do you need it if you can simply run USB stack in protected mode? On how many lines of code do you rely in "protected mode"? On Qubes, you assign the devices to VMs, hide them from the dom0, so they can't attack it. It relies on Xen, one of the most tested piece of software with a small Trusted Computing Base. See this: https://www.qubes-os.org/faq/#why-does-qubes-use-xen-instead-of-kvm-or-some-other-hypervisor https://www.qubes-os.org/faq/#why-does-qubes-use-xen-instead.... > Also, I assume that running so many VMs requires a lot of drive space and hurts performance. You need a lot of RAM, if you want to run a lot of VMs simultaneously. But you don't have to. CPU performance should not be affected much. Drive space is saved by using TemplateVMs (which provide root partition to other VMs): https://www.qubes-os.org/doc/templates/ https://www.qubes-os.org/doc/templates/.
- pjmlp 4y agoOur industry will only change when security exploits come with hard penalties for the companies that don't take security seriously, just like any food joint gets closed down when visited by the sanitary authorities and doesn't upheld the very minimum health conditions. Until then, rinse and repeat as you say.
- netheril96 4y agoYou can’t impose penalties for free and open source projects though. Well, you can, but that results in much fewer open source projects being ever developed.
- pjmlp 4y agoSure you can, just like people selling street food have to take care no one gets food poison.
- kraemahz 4y agoI am competent enough to read c and note that none of those changes you highlighted have functional impacts. They were largely cosmetic changes (e.g. removing an else condition by assigning the inclusive flags to a variable). I saw one change that looked like a performance improvement (an early loop exit break added). I will also note that rsync has a test suite and running tests as "integration" style testing is more common of shell utilities than writing gobs of unit tests. I would have liked to see an additional targeted test written for the CVE in this patch though.