Sam Hartman <hartm...@debian.org> writes: > You talk a number of times about whether an attack is possible against > salsa. But especially when thinking about detection and tracing, I > think that things that are verified by signatures made with keys not > held by the system in question are harder to modify than things that can > be verified only so long as a system remains trusted.
I agree with this. > Which is to say, especially in the moment when considering an incident, > people are very bad about reasoning about whether views of a system are > equivalent. Yes, I agree with this too, and definitely include myself. These sorts of threats are very tricky to reason about and I have doubtless missed some. > So, I consider the following to be useful to an attacker--to be threats > worth mitigating: > 1) Attacker uploads malicious code to the archive. > 2) Attacker possibly through a compromise of the dgit server and salsa > changes the git view to be something harmless. I completely agree. An undetected compromise of Salsa in which an attacker makes the web view not match the Git repository is nasty, and I fear that attack could do a lot of damage, since we do a lot of our work via the web view and but what we upload to the repository is based on the Git repository. But I'm not sure that tag2upload makes this attack any worse. I think we already trust Salsa's view of Git archives quite a lot. This involves reasoning about sponsor behavior, which is always tricky since I can't view it personally, we don't really have much data, and there's a lot of variation between sponsors. But my guess is that the workflow of reviewing code on Salsa (possibly incrementally via MRs) and then doing a git pull, building a source package, and uploading it without further review is very common. So I think you are correctly identifying a risk that I didn't talk about in my security review, but I'm also not sure that it's relevant to a differential comparison of life before tag2upload and life after tag2upload. Maybe tag2upload does make us more vulnerable to this by changing behavior: if the existence of tag2upload shifts sponsors from doing code reviews locally on exactly the thing that they're going to turn into a source package to doing code reviews via the Salsa view and then blindly signing a git pull, that does make us more vulnerable to Salsa compromises where an attacker can make those two views not match. But I'm not sure I see a reason why that would be the case. > Such an attack can be detected by regularly verifying the archive > contents against git versions. Hm, can it? If the attacker has injected code into the Salsa Git repository but hidden it from the Salsa UI, wouldn't the verification step also use the Salsa Git repository as its point of reference, and thus miss the attack? I think this is a special case of an attacker sneaking malicious code into a package past the audit of a sponsor so that a sponsor unknowingly signs that malicious code and uploads it into the archive. There are several ways to perform that attack, including just making the code complicated and annoying to review and relying on the sponsor not spotting the problem. This is a particularly nasty variation since it can also affect packages that aren't sponsored, assuming that the maintainer doesn't notice commits snuck into their package that they didn't make, but I think the implication is roughly the same. I don't think Debian has very good protections against this attack either with or without tag2upload, and I don't think tag2upload changes the properties of this attack very much. It provides some assistance around the edges by forcing all of the code into Git, where we at least have a better tracing story, but I would not rely on that to head off this attack. > Still, my initial read of your analysis is that you discount attacks > like this more than makes sense to me. That's not my intent. I did think about some attacks like that (not that one in particular, but various similar sponsorship scenarios) and my intent was to say that I didn't think tag2upload changed the problem one way or the other. I think some of that got lost in editing. Maybe I'm missing some reason why tag2upload is more vulnerable to attacks of this type, though? -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
