search

haskell / haskell-ide-engine

The engine for haskell ide-integration. Not an IDE
BSD 3-Clause "New" or "Revised" License
2.38k stars 211 forks source link

TCP is insecure against local attackers #196

Open DemiMarie opened 8 years ago

DemiMarie commented 8 years ago

TCP sockets, even bound to localhost, are insecure against local attackers. To solve this, either TCP sockets must not be used or strong cryptographic authentication (such as HMAC of all messages) must be mandatory.

alanz commented 8 years ago

What precisely are we defending against? If it is local only, then if the machine is compromised we are in trouble anyway.

If it is remote, then it is not strictly hie's use case/domain. If anything, remote connections should use TLS/SSL as a way to secure the connection without major interference in the protocol.

At this point in hie development, I do not believe it is a big issue.

However, PR's welcome.

cocreature commented 8 years ago

I don’t see how security is relevant for editor tooling or even possible without jumping through quite some hoops. If it’s local both ends are available to the attacker so any encryption is useless. If you want to use it remotely you’re probably best off establishing a VPN tunnel or something like that. SSL is not really useful here, you would need to sign the cert for hie on the server side which really doesn’t seem like something you want to have to do to get type info in emacs.

Overall unless @drbo presents a good reason why we should care about security I would prefer to keep it simple and use vpn/ssh tunnels for remote connections.

DanielG commented 8 years ago

I think we should use unix domain sockets on system supporting them and TCP everywhere else (i.e. WinDOS) it would theoretically be possible to use named pipes on WinDOS but I don't think there is a haskell library that supports it yet so it would be a pain to implement.

alanz commented 8 years ago

I think we should note those as possible mitigation approaches, and ignore it for now, we have bigger fish to fry

On Tue, Mar 29, 2016 at 10:36 PM, Daniel Gröber notifications@github.com wrote:

I think we should use unix domain sockets on system supporting them and TCP everywhere else (i.e. WinDOS) it would theoretically be possible to use named pipes on WinDOS but I don't think there is a haskell library that supports it yet so it would be a pain to implement.

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/haskell/haskell-ide-engine/issues/196#issuecomment-203088972

DanielG commented 8 years ago

In principle I agree but these things have a way of sticking and it is really rather very painless to switch to domain sockets since they behave exactly as tcp sockets do except the address is a filename instead of a number.

alanz commented 8 years ago

+1, PR welcome

mgsloan commented 8 years ago

Agreed on using domain sockets when possible, ide-backend has some code for this.

cocreature commented 8 years ago

While I’m open to adding a way to use domain sockets, the primary reason why we added a TCP transport (apart from emacs being stupid) was to support the usecase where hie is running inside of a docker container (or something similar). While it’s probably possible to do this via a shared folder it feels kinda weird, also running it completely remotely will not be possible. For those reasons I think it makes sense to keep the TCP transport.

cocreature commented 8 years ago

Also windows does not support domain sockets (although they support similar things) which iirc was one of the reasons for ide-backend not supporting windows (at least in the beginning).

mgsloan commented 8 years ago

Definitely keep the TCP sockets! This is just an optional optimization.

DemiMarie commented 8 years ago

Other user accounts on the same machine.

Windows (NT and later) and *nix are multi-user systems, and it is possible for mutually distrusting users to share a machine. TCP on localhost is insecure in that case in the absance of strong authentication.

On Tue, Mar 29, 2016 at 12:54:23PM -0700, Alan Zimmerman wrote:

What precisely are we defending against? If it is local only, then if the machine is compromised we are in trouble anyway.

If it is remote, then it is not strictly hie's use case/domain. If anything, remote connections should use TLS/SSL as a way to secure the connection without major interference in the protocol.

At this point in hie development, I do not believe it is a big issue.

However, PR's welcome.

You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/haskell/haskell-ide-engine/issues/196#issuecomment-203071878

bitemyapp commented 8 years ago

@drbo given containers and virtualization, it seems quite unlikely the TCP sockets would get exposed even if someone was (bizarrely) sharing dev machines running an IDE.

Unless you can contribute code for mitigation (getting named pipes working on Windows?) , it seems unlikely discussing this further will be terribly useful.

Could wait out the Windows Linux support (announced today) and just use UDSes too.

DemiMarie commented 8 years ago

Note that the security problems can be completely eliminated by requiring strong cryptographic authentication of both parties prior to transmission of any data. Unlike the case of remote TCP, no encryption is required, though it would be desirable (in case of weird problems

Emacs can support AF_UNIX sockets with no problems.

On Windows, it is probably better to use a strong authenticated encryption algorithm such as libsodium's crypto_secretbox, or at least a strong MAC such as Blake2b (faster, preferred) or SHA512-HMAC (slower), both in libsodium.

DemiMarie commented 8 years ago

@bitemyapp Shared machines are VERY common in academia.

The ones I have worked on don't use containers or virtualization, just standard Unix accounts – hence why the use of TCP sockets without authentication is a problem.

nponeccop commented 6 years ago

Since pipes are normal files with special names, I think we could attack the issue by implementing named pipes API in Win32 library

DemiMarie commented 6 years ago

There is also my SlipRock library (https://github.com/DemiMarie/SlipRock) which I am working on.

On Mon, Dec 4, 2017 at 8:07 PM, nponeccop notifications@github.com wrote:

Since pipes are normal files with special names, I think we could attack the issue by implementing named pipes API https://msdn.microsoft.com/en-us/library/windows/desktop/aa365590(v=vs.85).aspx in Win32 library https://github.com/haskell/win32

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/haskell/haskell-ide-engine/issues/196#issuecomment-349161077, or mute the thread https://github.com/notifications/unsubscribe-auth/AGGWB6Jiq3uE0Nhe8R2Hkp4VtW_CqBcPks5s9JdFgaJpZM4H7Ebn .

nponeccop commented 6 years ago

Bringing in libuv seems too much to me. Maybe you could help @winterland1989 to finish his work on libuv integration into GHC itself: https://github.com/winterland1989/stdio/tree/libuv/bench/libuv , https://ghc.haskell.org/trac/ghc/ticket/8400

winterland1989 commented 6 years ago

@nponeccop, I'm busy with creating an full stack app these days, i'll come back to I/O topic in next month hopefully.