Hi, Here's the summary of the IRC meeting. ---
COMMUNITY 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: <https://community.openvpn.net/openvpn/wiki/Topics-2018-04-18> The next meeting has not been scheduled yet. Your local meeting time is easy to check from services such as <http://www.timeanddate.com/worldclock> SUMMARY 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
bump"
(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
attacker?
(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
"nah!"
(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
that
(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
himself?
(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
stuff
(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
available
(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
case
(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
possible
(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
rights.
(13:14:56) cron2: plaisthos: lacking context. How would the full text look
like?
(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
debugging
(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
logging.
(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
any")
(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
response
(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
time
(13:33:37) mattock: my stomach is doing the same
(13:33:45) mattock: let's conclude here
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 Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
