Boundary comes with built-in wrappers for ssh, rdp, and postgres, but you can "boundary exec" to run some other application inside the TCP-wrapped transport, apparently.
Some sort of LD_PRELOAD style trickery? Or are they intercepting syscalls?
edit: seems nothing that complicated, more like ssh-style tunnel where Boundary has a local listening socket which you need to point the client to. That is if I'm understanding it correctly.
So does it intercept all connections on that port (from the client app) and pass them along? Or do I need to reconfigure my client application to talk to localhost:whatever? Your only example is that curl using a hostname, it's not really clear.
mostly copy-pasta from an earlier comment[0] of mine:
https://github.com/99designs/aws-vault/issues/578 was for an issue with remote servers accessing the localhost ec2 metadata service that aws-vault can run, that worked exactly by using DNS rebinding. It was fixed only months ago, so it seems like this is a developing area and if I were on a red team or pen testing, I would play around with more.
I visualize the "localhost hole" problem of blindly trusting localhost as an air gap in a pipe (like [0]); anybody could come along and either drop poison in the pipe, or redirect the water coming from the top to their own bucket, or both.
I appreciate that Boundary gives completely generic identity-aware-authenticated TCP sockets, but I don't know of a way, today, to make those not accessible to browsers through dns rebinding attacks.
This is probably much much too far in the weeds and this is unlikely to contribute to a major breach (unlike the aws-vault one where of course attackers would try to access the fake metadata service on the default port, because it's high-value and on a well-known port), but I'm interested in the space.
edit: seems nothing that complicated, more like ssh-style tunnel where Boundary has a local listening socket which you need to point the client to. That is if I'm understanding it correctly.