This makes no sense. It's marginally less safe to accept UDP packets than TCP packets, for which you at least need to complete a 3WH to deliver frames. I don't think you've thought this through.

▲

codethief a day ago | parent [-]

IIUC the parent's point is that if you first have to unwrap incoming, say, HTTPS traffic to obtain the Wireguard UDP packets, that unwrapping code might contain vulnerabilities, so an attack compromising the machine Wireguard is running on might occur before the packets ever reach the Wireguard implementation. From where I stand that's a somewhat academic scenario, though. (Unwrapping correctly & safely is usually not that difficult. Just don't use a memory-unsafe language for parsing & unpacking maybe.)

▲

tptacek a day ago | parent [-]

I address that at length 2 comments back.

	▲	aboardRat4 a day ago \| parent [-]
		No you did not. Wrapping-Unwrapping code is irrelevant to the security of wireguard. Even if your wrapper-unwrapper is an outright remote shell without authorization, it would do nothing to compromise wireguard itself, as long as that shell has no sudo. But in any case, that wrapper-unwrapper is usually just a packet rewriter, port-to-port, runs as a disabled user with no login privileges, no shell, and in a chroot. The only thing your RCE can do is to exit(1) the rewriter itself.