3 ms·

Indeed. This whole post is a nothingburger since the "attack" requires the attacker to already be on the wrong side of the airtight hatchway.

dundarious 3y ago
The "airtight hatchway" argument is that it's not a security bug in the program. I don't think TFA makes the case that it is a security bug, so it's moot. Personally I'm not particularly moved by the lolbin and footgun case it does make. I am just mildly put off by how text editors and IDEs are inextricably bundled with so many double-edged remote capabilities.
- shadowgovt 3y ago
  They are nowadays competing with cloud services for users. Increasingly, being able to manipulate data on a machine other than the one I'm currently physically sitting at is table stakes features.
- _cenw 3y ago
  This. I'd be more worried some worker opens up a piece of internal infrastructure deliberately to make their work life easier instead of an attacker taking advantage of the binary being trusted.
xg15 3y ago
Isn't the whole "airtight hatchway" concept mostly invalidated today by "defense in depth" an "zero-trust networking" paradigms? Effectively, the airtight hatchway often isn't, so you do have to think about cases where the attacker is behind it. E.g., it used to be an effective security measure to have a daemon listen on loopback only. But then browsers relaxed the same-origin policy and today every sleazy banner ad can get the browser to open a TCP connection on loopback and at least send a TLS handshake - and, if the daemon accepts that, an OPTIONS request with an attacker-controlled URL. So a daemon has to perform at least some basic validation on incoming connections to be secure.
- plorkyeran 3y ago
  Zero-trust networking still involves threat models and things which you are and aren't trying to defend against. The "airtight hatchway" concept is just that once you've declared that a certain type of attack isn't something you're trying to prevent, there's no point in reporting issues which rely on that attack because it's already known to be vulnerable. Defense in depth can be seen as adding multiple hatchways, but there's still always going to be something inside the innermost one. If your threat model involves people trying to exfiltrate data from a developer machine with an internet connection in an innocent-looking way, this VSC feature is a problem. Most companies either don't make an attempt at preventing that, or would use an airgapped setup so it's not something worth caring about.
  - Dylan16807 3y ago
    > Defense in depth can be seen as adding multiple hatchways, but there's still always going to be something inside the innermost one. And even if you're not in the innermost area, an attack might exist entirely in the space between two hatchways and not breach any.
- josephcsible 3y ago
  Isn't this validly described as "it lets you execute commands as a particular user on a particular host, but requires you to first execute a command as that user on that host"? Even in "defense in depth" or "zero-trust networking" paradigms, what does this ever let attackers do that they couldn't do already?

dundarious 3y ago

The "airtight hatchway" argument is that it's not a security bug in the program. I don't think TFA makes the case that it is a security bug, so it's moot. Personally I'm not particularly moved by the lolbin and footgun case it does make. I am just mildly put off by how text editors and IDEs are inextricably bundled with so many double-edged remote capabilities.

shadowgovt 3y ago
They are nowadays competing with cloud services for users. Increasingly, being able to manipulate data on a machine other than the one I'm currently physically sitting at is table stakes features.
_cenw 3y ago
This. I'd be more worried some worker opens up a piece of internal infrastructure deliberately to make their work life easier instead of an attacker taking advantage of the binary being trusted.

xg15 3y ago

Isn't the whole "airtight hatchway" concept mostly invalidated today by "defense in depth" an "zero-trust networking" paradigms? Effectively, the airtight hatchway often isn't, so you do have to think about cases where the attacker is behind it. E.g., it used to be an effective security measure to have a daemon listen on loopback only. But then browsers relaxed the same-origin policy and today every sleazy banner ad can get the browser to open a TCP connection on loopback and at least send a TLS handshake - and, if the daemon accepts that, an OPTIONS request with an attacker-controlled URL. So a daemon has to perform at least some basic validation on incoming connections to be secure.

plorkyeran 3y ago
Zero-trust networking still involves threat models and things which you are and aren't trying to defend against. The "airtight hatchway" concept is just that once you've declared that a certain type of attack isn't something you're trying to prevent, there's no point in reporting issues which rely on that attack because it's already known to be vulnerable. Defense in depth can be seen as adding multiple hatchways, but there's still always going to be something inside the innermost one. If your threat model involves people trying to exfiltrate data from a developer machine with an internet connection in an innocent-looking way, this VSC feature is a problem. Most companies either don't make an attempt at preventing that, or would use an airgapped setup so it's not something worth caring about.
- Dylan16807 3y ago
  > Defense in depth can be seen as adding multiple hatchways, but there's still always going to be something inside the innermost one. And even if you're not in the innermost area, an attack might exist entirely in the space between two hatchways and not breach any.
josephcsible 3y ago
Isn't this validly described as "it lets you execute commands as a particular user on a particular host, but requires you to first execute a command as that user on that host"? Even in "defense in depth" or "zero-trust networking" paradigms, what does this ever let attackers do that they couldn't do already?