Ensure that team members use a non-vulnerable version of OpenVPN

[achave11-ucsc]

Hello,

We are reaching out to you because we have identified that you use Client VPN, which supports the OpenVPN protocol [1].

AWS is aware of CVE-2023-36671 and CVE-2023-36673. When using an untrusted network, an actor with control over DNS resolution of the VPN server's IP address could leverage VPN routing behavior to monitor plaintext traffic. AWS is also aware of CVE-2023-36672 and CVE-2023-35838, which could allow plaintext local network traffic to be monitored or blocked when an actor gains control of the IP address range assigned to the local network. This may occur when using untrusted networks.

We have mitigated all 4 CVEs on all platforms and strongly recommend that customers upgrade to version 3.9.0+ for Windows, 3.7.0+ for macOS, and 3.8.0+ for Linux [2]. All previous versions of the AWS provided Desktop VPN Client are affected and are no longer available for download.

If you are not using the AWS VPN Client Desktop software or are using OpenVPN open source Desktop software, we encourage you to evaluate the security posture of the software you are using.

If you have questions or concerns, please contact AWS Support [3].

[1] https://aws.amazon.com/vpn/client-vpn/ [2] https://aws.amazon.com/vpn/client-vpn-download/ [3] https://aws.amazon.com/support

Sincerely, Amazon Web Services

Amazon Web Services, Inc. is a subsidiary of Amazon.com, Inc. Amazon.com is a registered trademark of Amazon.com, Inc. This message was produced and distributed by Amazon Web Services Inc., 410 Terry Ave. North, Seattle, WA 98109-5210

---

Reference: https://phd.aws.amazon.com/phd/home?region=us-east-1#/event-log?eventID=arn:aws:health:global::event/CLIENT_VPN/AWS_CLIENT_VPN_SECURITY_NOTIFICATION/AWS_CLIENT_VPN_SECURITY_NOTIFICATION_764c35f36a7bc20197ed5c9603106db804eede4745d72d30354a680c8332c7fb&eventTab=details

-- You received this message because you are subscribed to the Google Groups "Azul (aka Team Boardwalk)" group. To unsubscribe from this group and stop receiving emails from it, send an email to azul-group+unsubscribe@ucsc.edu. To view this discussion on the web visit https://groups.google.com/a/ucsc.edu/d/msgid/azul-group/01000189d7785250-8030c0fe-566a-4659-a1b3-ba47f3fd8fc8-000000%40email.amazonses.com.

[achave11-ucsc]

Spike to investigate if the mentioned CVEs affect OpenVPN and if so, which versions.

[hannes-ucsc]

I'll be taking this spike.

[hannes-ucsc]

All of the CVEs mentioned are different expressions of the TunnelCrack exploit. This exploit relies on the client to be joining a local network that is at least partially controlled by the attacker so that the attacker can spoof DNS responses or control the DHCP responses sent to the client. In essence, if the local network of the client is untrusted, the client can then be tricked into bypassing the tunnel, even for traffic that should be tunneled. In other words, the exploit tricks the client into splitting the tunnel.

From the paper it appears that Viscosity is vulnerable. It is unclear to me from reading the paper, if nmcli/openvpn on Ubuntu are vulnerable. At least some versions appear to be.

The exploit is valid and affects many VPNs. It requires the cooperation of the operating system network stack, DHCP and DNS clients. I feel that there is some work to do for the community to come up with an airtight mitigation. I expect some mitigations that are available now, such as the one made available by AWS (see the advisory quoted in the description), are in fact incomplete and are still vulnerable, just with a more complicated exploit.

Note that we are intentionally using split tunneling for our system so that only traffic to the remote network (the network at tunnel exit) is tunneled because anything else would be impractical. We frequently have multiple VPNs open at any time (to more than one deployment) and often transfer large amounts of data (docker images, for example) to and from the internet.

Because of the fact that we intentionally use split tunneling, we might be tempted to say that the exploit is irrelevant for us. However, I am not sure I feel comfortable with using our developer machine in untrusted local networks at all, regardless of whether a VPN is active or whether the split is intentional or not. We should update our policies to prohibit use of developer machines outside of trusted networks. Trusted networks should be defined as ones operated by UCSC or the developer themselves (their home network, connected to an ISP like Comcast).

@nolunwa-ucsc, would you be able to spearhead that policy update?

[hannes-ucsc]

This is SC-7(7) to be specific.

[nolunwa-ucsc]

@hannes-ucsc i agree with your suggestion. It is implied in the SSP but will be include this as a rule in the UCSC Data Browser ROB.

Nneka to also update PE-17 and SC-7(7)

[nolunwa-ucsc]

updated the access agreement and notified @hannes-ucsc to review

[hannes-ucsc]

I reviewed the document.