Haskell-ide-engine: TCP is insecure against local attackers
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.
DemiMarie
All 18 comments
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.
alanz
on 29 Mar 2016
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.
cocreature
on 29 Mar 2016
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.
DanielG
on 29 Mar 2016
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 [email protected]
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
alanz
on 29 Mar 2016
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.
DanielG
on 29 Mar 2016
+1, PR welcome
alanz
on 29 Mar 2016
Agreed on using domain sockets when possible, ide-backend has some code for this.
mgsloan
on 29 Mar 2016
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
on 30 Mar 2016
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).
cocreature
on 30 Mar 2016
Definitely keep the TCP sockets! This is just an optional optimization.
mgsloan
on 31 Mar 2016
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
DemiMarie
on 31 Mar 2016
@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.
bitemyapp
on 31 Mar 2016
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
on 31 Mar 2016
@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.
DemiMarie
on 31 Mar 2016
Since pipes are normal files with special names, I think we could attack the issue by implementing named pipes API in Win32 library
nponeccop
on 5 Dec 2017
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
.
DemiMarie
on 5 Dec 2017
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
nponeccop
on 5 Dec 2017
@nponeccop, I'm busy with creating an full stack app these days, i'll come back to I/O topic in next month hopefully.
winterland1989
on 5 Dec 2017
Related issues
alanz
·
3Comments
JorisBlanken
·
4Comments
IvanMalison
·
5Comments
rvion
·
3Comments
alanz
·
3Comments
Most helpful comment
@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.