Here's the summary of the IRC meeting.


Place: #openvpn-meeting on irc.freenode.net
Date: Wednesday 18th Apr 2018
Time: 11:30 CET (10:30 UTC)

Planned meeting topics for this meeting were here:


The next meeting has not been scheduled yet.

Your local meeting time is easy to check from services such as



cron2, dazo, mattock, ordex, plaisthos and syzzer participated in
this meeting.


Discussed upcoming OpenVPN 2.4.6 release. It will contain what
release/2.4 has now, plus one security fix which is under embargo. The
tree will be pushed to buildbot tomorrow afternoon after which the
release machinery starts for good.

The 2.4.6 release will include an updated tap-windows6 driver with a
small security fix. The fix will not get a CVE as exploitation requires
local admin privileges and is not remotely exploitable. It was agreed
that we should update PRODUCT_VERSION in tap-windows6 from 9,0,0,21 to
9,22,1,601. This means it will be in-line with the real version
(9.22.1). The old, confusing PRODUCT_VERSION string seems to be just
historic baggage brought over from tap-windows (i.e. the old NDIS 5 driver).


Discussed unit testing the netlink code and in particular the msg()
function. Noted that we have mock_msg.c already which does minimal
logging, which renders it more suitable for unit testing.


Discussed the location of the next hackathon. One possibility is Lviv,
Ukraine, where OpenVPN Inc. has a rather large team. It is easily
accessible for EU citizens as no visa is required.


Full chatlog attached.

Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

irc freenode net: mattock

(12:34:48) mattock: ok let's start
(12:34:58) mattock: 2.4.6
(12:35:16) cron2: there's two aspects to it
(12:35:45) cron2: one is "openvpn", and that is fairly easily summarized: "what 
we have in tree right now, plus the CVE fix (iservice), plus the version number 
(12:36:06) ***cron2 will get the tree ready tomorrow afternoon and push to 
mattock's repo on build.openvpn.net
(12:36:18) cron2: and when the release is out, push to all other repos
(12:36:32) cron2: ok?
(12:36:58) mattock: sounds good
(12:37:09) dazo: makes sense ... but do we need a CVE for tap-windows6?  I 
don't think so, but long time since I paid attention to the details here
(12:37:34) cron2: dazo: it's "if you have admin privileges already, you might 
be able to get your system to bluescreen"
(12:37:55) cron2: so while this is an annoying issue that must be fixed, nobody 
argued for CVE yet
(12:38:33) cron2: so, second half, tap-windows6 - what I see here right now is 
a few different issues
(12:38:48) cron2: - the overread patch (v4 on security@ list)
(12:38:55) cron2: - the version number bumping
(12:38:58) dazo: can this bluescreen (read: DoS) be triggered by a remote 
(12:39:01) cron2: - SHA2 signing
(12:39:18) cron2: dazo: no, because it has to be a link-local packet, which is 
validated before entering that code
(12:39:29) cron2: and fe80:: stuff is never forwarded from one interface to a 
different one
(12:40:22) dazo: okay ... so it would in worst case be a local DoS *if* the 
attacker has admin privileges - is that correct?
(12:40:32) cron2: this is how we currently read it
(12:41:09) cron2: it's overreading a kernel buffer by a few bytes, so depending 
on kernel memory layout, it might have no effects at all, or bluescreen
(12:41:49) dazo: okay ... technically, it could be a CVE .... but, I would say 
we can skip it this time ... if a local attacker has admin privileges, that is 
far more a severe issue
(12:42:05) mattock: +1
(12:42:10) cron2: +1
(12:42:23) mattock: regarding version number bump in tap-windows6
(12:42:44) mattock: I suggest setting PRODUCT_VERSION to 9,22,1,601
(12:42:53) mattock: right now it is 9,0,0,21
(12:42:56) mattock: which is confusing
(12:43:10) mattock: that shows up in the file properties dialog
(12:43:11) dazo: I know nothing about driver versioning .... but the change 
sounds fine to me if this is the right approach
(12:43:12) cron2: that would have been my suggestion as well - and then build 
another test installer, to see if things still work or magically fail
(12:43:19) ordex: (+1 for no-CVE :P, sorry for the delay)
(12:43:32) mattock: yeah, I will do another round of smoke-testing for the new 
tap-windows6 build
(12:43:37) cron2: dazo: we have no idea why things are the way they are, this 
is all "from the old age"
(12:43:47) mattock: probably leftovers from tap-windows
(12:43:49) dazo: :)
(12:43:58) mattock: for no good reason is my hunch
(12:44:05) cron2: mattock: I would suggest to merge the v4 patch "for good", so 
people testing this can be sure "this is what we have in master + the version 
bump test"
(12:44:10) syzzer: yeah, number sound very much like 'copied from tap-windows'
(12:44:33) syzzer: and the tap-windows thing feels very low impact indeed
(12:44:39) mattock: cron2: agreed
(12:44:54) cron2: since we are doing a release really soon now, I would 
basically also break the embargo on the tap-windows6 bug now - it's complicated 
enough with all the testing
(12:45:15) mattock: yep, and I definitely don't want to go through two rounds 
of tap-windows6 building and signing and testing
(12:45:18) mattock: it takes a long time
(12:45:20) syzzer: I think that's fine
(12:45:22) cron2: what about openvpn inc windows client?  I assume these folks 
are aware that they should do a new release then
(12:45:34) mattock: I made them aware but they have not reacted yet
(12:45:37) syzzer: does the commit message have some impact analysis in there?
(12:45:46) mattock: or should we add a page to Trac?
(12:45:51) dazo: mattock: lev should be able to follow up on that
(12:45:57) ordex: mattock: did you specifically targetted Lev ? he did not 
mention this in the last meeting
(12:45:58) syzzer: that usually helps with limiting the panic
(12:46:07) mattock: I sent the email to dev@
(12:46:20) dazo: I'll follow up with Lev
(12:46:23) mattock: ok, good
(12:46:24) ordex: yeah, thanks
(12:46:30) cron2: syzzer: not really, it just says "possible buffer overread"
(12:46:47) mattock: then you will start bugging me about building a 
tap-windows6 version _again_ because you need the adapter name to be different
(12:46:48) mattock: :P
(12:46:51) cron2: (you have the commit message in your mail somewhere :) )
(12:47:09) ordex: cron2: syzzer: maybe we should be more explicit on the impact 
to avoid people from paniking? or no need?
(12:47:12) cron2: mattock: I've wondered about the "tap0901" bit, and decided 
(12:47:24) mattock: I don't even know what that means
(12:47:30) mattock: let's keep it as it is
(12:47:37) mattock: otherwise all documentation will blow up
(12:47:42) cron2: ordex, syzzer: if you think it helps, I'm happy to send a v5 
(12:48:29) ordex: either in the commit or in some release notes together with 
the new driver/release I think ? syzzer ?
(12:49:09) dazo: +1
(12:49:29) mattock: commit is most likely not to get lost in time
(12:49:44) mattock: trac can go away, forums can go away, the website will go 
away :)
(12:49:50) ordex: git can't!
(12:49:51) ordex: :)
(12:50:02) cron2: "This bug can be triggered by a privileged local user sending 
a malformed raw IPv6 packet to the tun interface.  The effect is a buffer 
overread by a few bytes, which might have no effects at all or cause a 
bluescreen, depending on kernel memory layout."
(12:50:06) cron2: does this work?
(12:50:23) plaisthos: Yeah
(12:50:23) cron2: ".. malformed IPv6 packet over a raw socket interface ..."
(12:50:40) ordex: yep
(12:50:42) plaisthos: you should add wether the overread memory can leak or not
(12:50:52) plaisthos: or if it is "just" an acccess violation
(12:51:06) dazo: with the "raw socket" and plaisthos comments, I'm fine with 
(12:51:10) syzzer: plaisthos: +1
(12:51:14) syzzer: otherwise sounds good
(12:51:43) cron2: let me check
(12:52:52) cron2: no leaking
(12:53:19) cron2: the overread is basically "is this icmpv6 neighbour 
solicitation?  for the magic address?"
(12:54:00) cron2: so if these fields do not contain the right values, the 
packet is ignored.  *If* they contain the right values, they are also ignored, 
because the ICMPv6 header in the reply packet is built from scratch 
(12:54:31) cron2: so, the text reads as follow right now:
(12:54:33) cron2: "This bug can be triggered by a privileged local user sending 
a malformed
(12:54:36) cron2: IPv6 packet over a raw socket interface to the tun interface. 
 The effect
(12:54:39) cron2: is a buffer overread by a few bytes, which might have no 
effects at all
(12:54:41) cron2: or cause a bluescreen, depending on kernel memory layout.  
Memory contents
(12:54:44) cron2: overread will not be leaked."
(12:54:51) plaisthos: okay you can if it has a very specific value :)
(12:55:02) plaisthos: minimal information leakage ;)
(12:56:09) cron2: well, it *could* be used to test if there is a "135", "0" and 
"fe80::8" in there...
(12:56:33) ordex: in there == in the packet that was forged by the attacker 
(12:56:49) cron2: ordex: no, in the buffer "behind" the packet
(12:56:55) ordex: ah ok
(12:57:07) cron2: we check for IPv6 header length (ok) and then proceed to read 
the ICMPv6 header (which might not be in the buffer)
(12:57:08) ordex: in the overread part
(12:57:11) cron2: yes
(12:57:35) cron2: we do not copy values from there to the return packet, but we 
do "does this *all* match?"
(12:58:11) ordex: ok
(12:58:31) ordex: does not really sound like a leakage, no?
(12:59:01) dazo: not to me, if the leaked data is as predictable as cron2 says
(12:59:43) cron2: well, that's what we do - "is this nd? for us?" - which is 18 
of the 24 bytes there at all (the rest is "reserved" and "checksum")
(13:00:05) cron2: changing the "few bytes" to "up to 24 bytes"
(13:00:16) syzzer: this could have been an issue if an unprivileged attacker 
could use this to somehow test for password bytes/words or so
(13:00:30) dazo: yeah
(13:00:41) ordex: yap
(13:00:48) cron2: nah - first of all, he can't send them, then, he can only 
test "are all 18 bytes exactly what I expect or not"
(13:01:59) cron2: new wording:
(13:02:03) cron2: "This bug can be triggered by a privileged local user sending 
a malformed
(13:02:06) cron2: IPv6 packet over a raw socket to a link-local address on the 
the tun
(13:02:09) cron2: interface.  The effect is a buffer overread by up to 24 
bytes, which might
(13:02:12) cron2: have no effects at all or cause a bluescreen, depending on 
kernel memory
(13:02:15) cron2: layout.  Memory contents overread will not be leaked."
(13:02:29) cron2: emphasis on "link-local address" (= this can not, never, be 
injected remotely)
(13:02:44) plaisthos: sure about that?
(13:02:55) syzzer: I think that's fine, as the interesting leaking is 'to the 
outside world'
(13:02:59) plaisthos: also the vpn link?
(13:03:05) cron2: plaisthos: yes
(13:03:08) ordex: well, you can't bridge a tun interface and link-local packets 
are not routed
(13:03:23) ordex: (unless this can be applied to a tap interface)
(13:04:09) cron2: to plaisthos: if it comes in via VPN, the driver will not 
look - it only executes the magic code for "does it come from host-to-vpn side?"
(13:04:35) plaisthos: so you would need a bridge on the tap device in windows
(13:04:48) cron2: to ordex: this is interesting.  Bridged LAN-to-TAP (tap mode) 
would indeed forward link-locals, but *in tap mode*, the driver ignores all L3 
(13:05:06) ordex: ah ok in that case this piece of code is not executed?
(13:05:35) cron2: if you do bridged LAN-to-TAP and then put the TAP driver into 
tun mode, you can excercise this remotely - but there no use case I can see 
where this would ever be a useful configuration
(13:05:37) plaisthos: cron2: but since the drivers is always pretending to be a 
tap device to windows even in tun it would still work, right?
(13:05:39) cron2: ordex: right
(13:05:55) ordex: oh ok
(13:05:59) ordex: but still possible
(13:06:22) cron2: plaisthos: the driver knows whether it is expected to behave 
as tap driver ("just hand over ethernet frames") or tun ("strip ethernet header 
-> tun fd, answer arp and nd, add ethernet headers on tun fd -> tap interface")
(13:06:24) ordex: sounds like an ill-setup, not sure it could really work? the 
device would get an Eth frame while configured as tun? would that work at all?
(13:07:21) cron2: ordex: I think it would not work for anything useful (because 
on the way back tun->tap->bridge) the destination MAC address would not be 
(13:07:33) cron2: the tap driver always puts "the tap interface MAC" in the 
ethernet packets (when in tun mode)
(13:08:35) ordex: cron2: but on the way in (host->bridge->"tun") would it work? 
I mean, the tun interface would receive a Eth Frame while expecting a IP 
segment. shouldn't the packet be thrown away? or will it still be able to strip 
the eth header and process the packet?
(13:09:03) cron2: ordex: the tap driver will strip the ethernet frame in this 
(13:09:08) ordex: oh ok
(13:09:40) cron2: so if you set up things that way, it will not really "work" 
as in "you can get useful things done", *but* that way a remote exploit is 
(13:09:50) cron2: so if you have admin privs and set up a bridge...
(13:09:55) ordex: yeah
(13:10:18) ordex: maybe still worth mentioning, because "technically" possible, 
but not expected to be seen in any real world setup
(13:10:34) ordex: ?
(13:11:27) cron2: I'm not sure I can word that in a way which will not confuse 
people more...
(13:12:16) ordex: yeah, especially in a purposely short commit message...how 
about just mentioning "link-local" packet without saying whether this is a 
local or remote attack?
(13:12:26) ordex: *address or whatever
(13:12:54) cron2: "If bridging to a LAN interface, injection of a malformed 
packet over
(13:12:54) cron2: LAN->bridge->TAP adapter might be possible.  But if the TAP 
adapter is
(13:12:54) cron2: used in "tap" mode (which is the only config that a bridge 
setup can
(13:12:55) cron2: technically be used successfully), the problematic code is 
not executed."
(13:13:37) plaisthos: can only exploited by link-local packet send to the tun 
device by the local host. This can normally only happen with Admin/raw packet 
(13:14:56) cron2: plaisthos: lacking context.  How would the full text look 
(13:16:43) plaisthos: Thinking of something that is lesser scarier but I end up 
with similar texts like you have
(13:18:24) ordex: yeah,  "privileged user" is already mentioned..shouldbe enough
(13:20:16) mattock: we've reached the 50 minute milestone
(13:20:29) mattock: fyi :)
(13:20:36) ordex: ding dong
(13:20:37) cron2: ok, so I'll keep the text we have so far
(13:20:42) ordex: +1
(13:20:42) mattock: +1
(13:20:47) dazo: +1
(13:20:59) mattock: anything else we can discuss in ~10 minutes?
(13:21:36) ordex: I just have a quick question for sitnl/netlink
(13:21:36) cron2: v5 sent, ball thrown to mattock :)
(13:21:55) cron2: wow, that was fast, I already have my own copy
(13:22:34) cron2: ordex: go! 8 minutes left
(13:23:01) mattock: let's do netlink
(13:23:04) ordex: I am working on the unit-tests and I realized that 
unit-testing an object with calls to msg() is troublesome because of the 
dependencies it pulls in. Does it make sense to split the sitnl module in 
something even slimmer with no calls to msg() or any other etxernal 
functionality so that it can be easily unit-tested?
(13:23:23) ordex: or do you hav another trick for me?
(13:23:25) cron2: mock msg()?
(13:23:30) ordex: there you go
(13:23:30) ordex: :D
(13:23:32) syzzer: ordex: what can says
(13:23:34) syzzer: cron2
(13:23:42) ordex: cron2 yes we can
(13:23:51) ordex: ok will do, very stupid, but I lack experience with mocking 
stuff :P
(13:23:56) cron2: I have no idea *how* to do that, but syzzer will know :)
(13:24:09) ordex: mah I think I will just re-define it as no-op?
(13:24:10) syzzer: C was not exactly designed for this kind of thing :p
(13:24:14) dazo: that's actually the concept cmocka build upon, iirc :)
(13:24:33) cron2: syzzer: don't we already have a test where we need to mock 
something (coming from misc.c)?
(13:24:45) dazo: the argv stuff, iirc
(13:25:13) ordex: ok, I will check how we have done that
(13:25:32) cron2: haha
(13:25:36) cron2: you just link mock_msg.o :-)
(13:25:37) syzzer: yeah, the ones that have the wrap linker flags in Makefile.am
(13:25:45) dazo: ordex: iirc ... check out __wrap_parse_line in test_argv.c
(13:26:05) syzzer: contributed by Heike, actually, I just extended
(13:26:08) syzzer: Heiko
(13:26:10) cron2: faaar to complicated - we have a mock_msg.c in 
tests/unit_tests/openvpn/ already
(13:26:19) dazo: oh
(13:26:21) ordex: aah perfect!
(13:26:23) ordex: :)
(13:26:23) dazo: right :)
(13:26:38) cron2: actually it came from syzzer :)
(13:26:42) cron2: commit 3b185161de1254af746494007b7e81d17f632d4b
(13:26:46) cron2:     To test --tls-crypt with as few dependencies as possible, 
this adds a
(13:26:48) syzzer: I wrote mock_msg.c as a simpler alternative if you don't 
need the full wrapping power
(13:26:49) cron2:     mock implementation of msg() (or actually x_msg()).  For 
(13:26:51) cron2:     purposes, the mock implementation can be made to really 
log by calling
(13:26:54) cron2:     mock_set_debug_level(), but defaults to (almost) no 
(13:27:11) ordex: yeah, logging is not required
(13:27:48) ordex: ok, thanks!
(13:27:51) ordex: \o/
(13:28:16) mattock: 2 minutes left :P
(13:28:26) ordex: next hackathon?
(13:28:26) ordex: :D
(13:28:44) mattock: that will probably take more than 2 minutes
(13:28:56) cron2: do we have suggestions for a non-US locations already?
(13:28:57) ordex: do we have actual proposals for the locations other than US?
(13:29:00) ordex: eh!
(13:29:02) mattock: that said, Ukraine is one option as OpenVPN Inc has a 
rather large team there nowadays
(13:29:05) cron2: haha :)
(13:29:16) mattock: Lviv to be exact
(13:29:31) cron2: Ukraine is easy for europeans wrt visa (= "you do not need 
(13:29:36) ordex: if in November you wanna go to Thailand, just let me know :D
(13:29:38) mattock: yep so I've heard
(13:29:42) ordex: yap
(13:29:52) mattock: that seems like a warmer option :P
(13:30:15) ordex: hehe, for sure
(13:30:33) dazo: some of us in ovpn inc will travel there in about 1 month, so 
we can check out the possibilities ... and suggest it internally to see the 
(13:30:40) cron2: +1
(13:30:47) ordex: yap
(13:30:50) syzzer: sounds good :)
(13:30:58) ordex: mattock: we can meet there also without having an hackathon. 
we can find another excuse :P
(13:31:05) dazo: :-P
(13:31:23) mattock: ordex: indeed :)
(13:31:30) cron2: ordex: well, you all can, on company expenses :-)
(13:31:42) mattock: an excuse is all we need
(13:31:48) cron2: poor syzzer and I have to have an hackathon ;-)
(13:32:29) ordex: hehe
(13:32:34) ordex: we'll find a way to work this out :)
(13:33:17) cron2: cool ;-) - anyway, my wife is reminding me that it's feeding 
(13:33:37) mattock: my stomach is doing the same
(13:33:45) mattock: let's conclude here

Attachment: signature.asc
Description: OpenPGP digital signature

Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Openvpn-devel mailing list

Reply via email to