QUIC can be implemented in the application-space, as opposed to being in the operating system kernel. This generally invokes additional overhead due to context switches as data is moved between applications. However, in the case of QUIC, the protocol stack is intended to be used by a single application, with each application using QUIC having its own connections hosted on UDP. Ultimately the difference could be very small because much of the overall HTTP/2 stack is already in the applications (or their libraries, more commonly). Placing the remaining parts in those libraries, essentially the error correction, has little effect on the HTTP/2 stack’s size or overall complexity.[8]
So it seems to me, with QUIC, malicious hackers might not need a root-user-level hack any more to subvert the networking stack. They merely need to hack any app running with a non-administrator user’s account privileges, and attack the QUIC networking stack(s) found in userspace.
So I think QUIC, if it implements error correction in user space, not kernel space (as is customary for TCP and UDP), could provide a malicious hacker with some low hanging fruit to go after, if they can exploit any non-administrative user’s account.
Does this sound plausible, that a malicious hacker’s job becomes easier, when the QUIC networking stack is in user-space (say, as part of a web browser, or Syncthing itself), not kernel space?
I don’t see a reason explaining why you think that way.
The only thing that changes is retransmits, RTT calculations and other things related to reliable delivery are in userspace, the rest of the stuff (namely TLS etc) was always in userspace regardless if its UDP or TCP.
Well, maybe I should ask this more carefully. What doesn’t worry me are network stack things running in user space, vs. kernel space, which are in both cases protected by elevated privileges, which an end user’s hacked apps can’t mess with (since it’s not running with elevated privileges).
What does have me concerned is this: do the QUIC network stack things run without elevated privileges, such that a hacked app without elevated privileges could then gain control of the networking stack?
I think I see your point: since TLS already happens without elevated privileges (and would be prone to the hacking I describe), and we don’t worry about that, then why start worrying now, about QUIC also running without elevated privileges?
A hacked app, without elevated privileges but running as the same user as Syncthing, can access anything Syncthing can. This includes any and all files Syncthing can access and Syncthing’s configuration and keys. The networking stack, wherever it runs, is the least of your problems.
If the hacked app runs as another user it doesn’t get access to the Syncthing process and it doesn’t matter how and where Syncthing builds its networking packets.