3 ms·

I wouldn't be so sure about that, more RCEs are found on browsers because it's just such a popular attack vector. An RCE in git repos could go undetected for fa

I wouldn't be so sure about that, more RCEs are found on browsers because it's just such a popular attack vector. An RCE in git repos could go undetected for far far longer probably.

kragen 3y ago
the git codebase is roughly 100× smaller than chromium, so, all else being equal, you'd expect 600× more bugs of any kind in chromium — more bugs per day in chromium than bugs per year in git there are design considerations to consider, but it's not clear to me which way they shift the balance: chromium's sandboxing layer means that you need a sandbox escape, but, on the other hand, chromium intentionally downloads and executes malicious code all the time, and that's inherently riskier than what git does, which is efficiently synchronizing a merkle graph of blobs. it's hard to imagine that this matters more than the sheer size of the codebase, though chromium's churn rate is also much higher, so the rate of new bug production is higher
- 4gotunameagain 3y ago
  Sure, but this does not take into account the appeal for trying to exploit said codebases. Who pulls from an untrusted git instance ? Very very few people, hence the very low incentive to look for exploits. Who uses Chromium ? E-ve-ry-one.
  - kragen 3y ago
    i'm pretty sure people clone git repos from unknown github users all the time. i can't be the only one. and there's a special incentive to exploit those people: they're the ones who build the software that runs everywhere else, so if you can own their laptops, you own the world regardless, the nonexistence of security holes is a much, much better protection than insufficient incentives to find the undoubtedly numerous security holes
    - 4gotunameagain 3y ago
      I said git instance, not repo. I would imagine that by directly manipulating the cloning process and not just the repository, a larger attack vector could be exploited. But yes, I agree with the rest of your points
      - kragen 3y ago
        there's no such thing as a 'git instance'
        4gotunameagain 3y ago
        haha sure. so when you git clone something, it arrives to you through divination, and there is no larger attack vector once you can meddle with the entire communication part and not just the blobs and refs.
        kragen 3y ago
        in this case it arrives to you through apache, which gives git the contents of the files it requests, just like the filesystem does when you clone a repo off a usb pendrive. there's no git-specific code running on the server when you clone that url there is, however, a faster 'smart http' git cloning protocol which apache can't participate in, and that is indeed a potential attack surface. i don't think any of the bugs i linked upthread were in that protocol though

I wouldn't be so sure about that, more RCEs are found on browsers because it's just such a popular attack vector. An RCE in git repos could go undetected for far far longer probably.

kragen 3y ago

the git codebase is roughly 100× smaller than chromium, so, all else being equal, you'd expect 600× more bugs of any kind in chromium — more bugs per day in chromium than bugs per year in git there are design considerations to consider, but it's not clear to me which way they shift the balance: chromium's sandboxing layer means that you need a sandbox escape, but, on the other hand, chromium intentionally downloads and executes malicious code all the time, and that's inherently riskier than what git does, which is efficiently synchronizing a merkle graph of blobs. it's hard to imagine that this matters more than the sheer size of the codebase, though chromium's churn rate is also much higher, so the rate of new bug production is higher

4gotunameagain 3y ago
Sure, but this does not take into account the appeal for trying to exploit said codebases. Who pulls from an untrusted git instance ? Very very few people, hence the very low incentive to look for exploits. Who uses Chromium ? E-ve-ry-one.
- kragen 3y ago
  i'm pretty sure people clone git repos from unknown github users all the time. i can't be the only one. and there's a special incentive to exploit those people: they're the ones who build the software that runs everywhere else, so if you can own their laptops, you own the world regardless, the nonexistence of security holes is a much, much better protection than insufficient incentives to find the undoubtedly numerous security holes
  - 4gotunameagain 3y ago
    I said git instance, not repo. I would imagine that by directly manipulating the cloning process and not just the repository, a larger attack vector could be exploited. But yes, I agree with the rest of your points
    - kragen 3y ago
      there's no such thing as a 'git instance'
      - 4gotunameagain 3y ago
        haha sure. so when you git clone something, it arrives to you through divination, and there is no larger attack vector once you can meddle with the entire communication part and not just the blobs and refs.
        kragen 3y ago
        in this case it arrives to you through apache, which gives git the contents of the files it requests, just like the filesystem does when you clone a repo off a usb pendrive. there's no git-specific code running on the server when you clone that url there is, however, a faster 'smart http' git cloning protocol which apache can't participate in, and that is indeed a potential attack surface. i don't think any of the bugs i linked upthread were in that protocol though