VPN traffic leaks in IPv6/IPv4 dual-stack networks/hosts
Folks, FYI. This is might affect OpenBSD users employing e.g. OpenVPN: http://tools.ietf.org/html/draft-gont-opsec-vpn-leakages. For a project such as OpenVPN, a (portable) fix might be non-trivial. However, I guess OpenBSD might hook some PF rules when establishing the VPN tunnel, such that e.g. all v6 traffic is filtered (yes, this is certainly not the most desirable fix, but still probably better than having your supposedly-secured traffic being sent in the clear). Thanks, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Re: upstream vendors and why they can be really harmful
On Fri, Nov 23, 2012 at 5:11 AM, Marc Espie es...@nerim.net wrote: On Thu, Nov 22, 2012 at 01:27:46PM -0430, Andres Perera wrote: why would the runtime be attractive for rop? what configuration vm needs syscalls that would be attractive to an attacker that can change the address of a jump? does the runtime really need to open sockets, or spawn processes? (i'm not even talking about languages) [...] i'm completely serious. i can use a js vm and write a trivial systrace sandbox like ssh's which only allows read() you're only talking about one small aspect of security. Just because your javascript apps cannot interact with your OS doesn't make them secure. They also have to be reliable, not trample on each other memory, so that you get predictable behavior and only have to worry about logic errors in each app. People are *relying* on javascript to do real work. If you're depositing documents on servers. If you're using gmail. If you're using any kind of web app, basically. Every day, people say that high-level languages like java or js are more secure. They are missing the point. Just because they don't have buffer overflows doesn't protect them from sloppy developer errors. Just the opposite, actually: being stupid is no longer a barrier to writing production code, and you end up with idiots writing code, instead of being stopped right away by C's nastiness. Guys are not probably reading you enough. See http://lists.gnu.org/archive/html/gnu-system-discuss/2012-11/msg0.html and https://news.ycombinator.com/item?id=4821488 :-)
Re: upstream vendors and why they can be really harmful
Guys are not probably reading you enough. See http://lists.gnu.org/archive/html/gnu-system-discuss/2012-11/msg0.html and https://news.ycombinator.com/item?id=4821488 :-) Can you please take this to another mailing list or off-list? Developer's Lists These lists are for technical discussions of aspects of OpenBSD. Thanks.
Re: VPN traffic leaks in IPv6/IPv4 dual-stack networks/hosts
On Fri, Nov 23, 2012 at 12:44:32PM +0100, Henning Brauer wrote: * Fernando Gont ferna...@gont.com.ar [2012-11-23 12:09]: FYI. This is might affect OpenBSD users employing e.g. OpenVPN: http://tools.ietf.org/html/draft-gont-opsec-vpn-leakages. we're way less affected than other OSes, since we prefer inet over inet6 by default. targeted attacks could still work. Yes! But this wouldn't help any non-OpenBSD hosts behind an OpenBSD VPN gateway. block quick inet6 is more efficient in this case ;) I recommend ifconfig $foo -inet6 in any case :) In the section Mitigations to VPN traffic-leakage vulnerabilities of Fernando's paper it is suggested that a VPN client disables IPv6 globally if it is not going to send all IPv6 traffic over the tunnel as well. The problems with -inet6 in this context are that a) it isn't a global IPv6 on/off switch and b) that it deletes all configured addresses from the selected interface, so the VPN client could not restore the previous configuration after the VPN connection is terminated. In iked(8)'s case, IPv6 is supported but nothing is forwarded unless the related flows are configured. And even in this case, IKEv2 would use traffic selector negotiation, which is not yet implemented in iked, and disable or narrow the configured IPv6 flows based on the peer's configuration. Maybe traffic selector negotiation is a risk by itself (see RFC 5996, section 2.9). The mitigation section of the paper is not very clear about the IPv6 supported, but not used or negotiated case. Regarding iked(8), I would think about at least one of the following options: a) Just don't care about it and expect that admins configured pf and the interfaces correctly. b) Document it in the iked.conf(5) manpage near the packet filtering sections. c) Make sure that the any keyword for flows in iked.conf will cause iked to advertise both the IPv4 and IPv6 traffic selectors. This would at least mitigate some possible problems, for example with the Windows IKEv2 client which already asks for any IPv4 and IPv6 by default. d) Implement an automatic IPv6 kill switch in iked that follows the suggestion to disable all IPv6 traffic if we have an IPv4-only tunnel. iked(8) could use a pf anchor to load a block rule, disable net.inet6.ip6.forwarding, or we could add a knob net.inet6.enable=0 that doesn't alter the configured routes and addresses and simply returns somewhere in the network stack (ugh). e) Just switch everything to IPv6 today. Oh wait, OpenBSD would have a reversed problem in this case by looking up IPv4 on dual-stack setups first *g*. Haha, I'm wondering if we'll ever see any serious security problems because of legacy IPv4 in an IPv6-world... Reyk
Re: VPN traffic leaks in IPv6/IPv4 dual-stack networks/hosts
On 11/23/2012 08:44 AM, Henning Brauer wrote: * Fernando Gont ferna...@gont.com.ar [2012-11-23 12:09]: FYI. This is might affect OpenBSD users employing e.g. OpenVPN: http://tools.ietf.org/html/draft-gont-opsec-vpn-leakages. we're way less affected than other OSes, since we prefer inet over inet6 by default. targeted attacks could still work. What about preference in terms of DNS transport? (e.g., when you've learned recursive DNS servers by means of DHCPv4, but also by means of RAs?) There could also be a scenario in which the attacker intentionally disables the v4 connectivity, such that you only have v6. I recommend ifconfig $foo -inet6 in any case :) Is anything like this triggered by default along with the tunnel-establishment process? The OpenVPN folks are aware about this issue, but they are probably going to wait till the have some sort of portable fix for this issue. Cheers, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
set ifp-if_baudrate with IF_Gbps() / IF_Mbps()
set ifp-if_baudrate with IF_Gbps() / IF_Mbps(). OK ? Index: if_ste.c === RCS file: /cvs/src/sys/dev/pci/if_ste.c,v retrieving revision 1.48 diff -u -p -r1.48 if_ste.c --- if_ste.c18 Oct 2012 21:44:21 - 1.48 +++ if_ste.c23 Nov 2012 14:07:41 - @@ -931,7 +931,7 @@ ste_attach(struct device *parent, struct ifp-if_ioctl = ste_ioctl; ifp-if_start = ste_start; ifp-if_watchdog = ste_watchdog; - ifp-if_baudrate = 1000; + ifp-if_baudrate = IF_Mbps(100); IFQ_SET_MAXLEN(ifp-if_snd, STE_TX_LIST_CNT - 1); IFQ_SET_READY(ifp-if_snd); bcopy(sc-sc_dev.dv_xname, ifp-if_xname, IFNAMSIZ); Index: if_tl.c === RCS file: /cvs/src/sys/dev/pci/if_tl.c,v retrieving revision 1.51 diff -u -p -r1.51 if_tl.c --- if_tl.c 22 Jun 2011 16:44:27 - 1.51 +++ if_tl.c 23 Nov 2012 14:07:42 - @@ -2125,7 +2125,7 @@ tl_attach(parent, self, aux) ifp-if_ioctl = tl_ioctl; ifp-if_start = tl_start; ifp-if_watchdog = tl_watchdog; - ifp-if_baudrate = 1000; + ifp-if_baudrate = IF_Mbps(100); IFQ_SET_MAXLEN(ifp-if_snd, TL_TX_LIST_CNT - 1); IFQ_SET_READY(ifp-if_snd); bcopy(sc-sc_dev.dv_xname, ifp-if_xname, IFNAMSIZ); Index: if_txp.c === RCS file: /cvs/src/sys/dev/pci/if_txp.c,v retrieving revision 1.104 diff -u -p -r1.104 if_txp.c --- if_txp.c5 Apr 2011 18:01:21 - 1.104 +++ if_txp.c23 Nov 2012 14:07:42 - @@ -225,7 +225,7 @@ txp_attachhook(void *vsc) ifp-if_ioctl = txp_ioctl; ifp-if_start = txp_start; ifp-if_watchdog = txp_watchdog; - ifp-if_baudrate = 1000; + ifp-if_baudrate = IF_Mbps(100); IFQ_SET_MAXLEN(ifp-if_snd, TX_ENTRIES); IFQ_SET_READY(ifp-if_snd); ifp-if_capabilities = 0; Index: if_vge.c === RCS file: /cvs/src/sys/dev/pci/if_vge.c,v retrieving revision 1.51 diff -u -p -r1.51 if_vge.c --- if_vge.c22 Jun 2011 16:44:27 - 1.51 +++ if_vge.c23 Nov 2012 14:07:42 - @@ -787,7 +787,7 @@ vge_attach(struct device *parent, struct ifp-if_ioctl = vge_ioctl; ifp-if_start = vge_start; ifp-if_watchdog = vge_watchdog; - ifp-if_baudrate = 10; + ifp-if_baudrate = IF_Gbps(1); #ifdef VGE_JUMBO ifp-if_hardmtu = VGE_JUMBO_MTU; #endif Index: if_vr.c === RCS file: /cvs/src/sys/dev/pci/if_vr.c,v retrieving revision 1.117 diff -u -p -r1.117 if_vr.c --- if_vr.c 20 Oct 2012 16:12:22 - 1.117 +++ if_vr.c 23 Nov 2012 14:07:42 - @@ -623,7 +623,7 @@ vr_attach(struct device *parent, struct ifp-if_ioctl = vr_ioctl; ifp-if_start = vr_start; ifp-if_watchdog = vr_watchdog; - ifp-if_baudrate = 1000; + ifp-if_baudrate = IF_Mbps(100); ifp-if_capabilities = 0; IFQ_SET_READY(ifp-if_snd); bcopy(sc-sc_dev.dv_xname, ifp-if_xname, IFNAMSIZ); Index: if_wb.c === RCS file: /cvs/src/sys/dev/pci/if_wb.c,v retrieving revision 1.49 diff -u -p -r1.49 if_wb.c --- if_wb.c 18 Oct 2012 21:44:21 - 1.49 +++ if_wb.c 23 Nov 2012 14:07:42 - @@ -794,7 +794,7 @@ wb_attach(parent, self, aux) ifp-if_ioctl = wb_ioctl; ifp-if_start = wb_start; ifp-if_watchdog = wb_watchdog; - ifp-if_baudrate = 1000; + ifp-if_baudrate = IF_Mbps(100); IFQ_SET_MAXLEN(ifp-if_snd, WB_TX_LIST_CNT - 1); IFQ_SET_READY(ifp-if_snd);
Re: VPN traffic leaks in IPv6/IPv4 dual-stack networks/hosts
On 11/23/2012 11:12 AM, Reyk Floeter wrote: In the section Mitigations to VPN traffic-leakage vulnerabilities of Fernando's paper it is suggested that a VPN client disables IPv6 globally if it is not going to send all IPv6 traffic over the tunnel as well. The problem is that even if you tried to send all IPv6 traffic over the VPN, the mechanism to achieve that might be non-trivial. e.g., some VPN implementations install more specific routes that override (i.e longest matching prefix thing) the existing default route. -- but there are a plethora of vectors that might be leveraged to install even more specific routes than those (Route Information Options, ICMPv6 Redirects, etc.). That is, getting all the v6 traffic on the VPN tunnel might be tricky. a) Just don't care about it and expect that admins configured pf and the interfaces correctly. This one doesn't seem to obey the principle of least surprise. Many people are not aware about the implications of v6 on their v4-only networks. d) Implement an automatic IPv6 kill switch in iked that follows the suggestion to disable all IPv6 traffic if we have an IPv4-only tunnel. iked(8) could use a pf anchor to load a block rule, disable net.inet6.ip6.forwarding, or we could add a knob net.inet6.enable=0 that doesn't alter the configured routes and addresses and simply returns somewhere in the network stack (ugh). This seems a sensible thing to do. Cheers, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Re: set ifp-if_baudrate with IF_Gbps() / IF_Mbps()
On Fri, Nov 23, 2012 at 11:57:50AM -0200, Gleydson Soares wrote: set ifp-if_baudrate with IF_Gbps() / IF_Mbps(). OK ? Index: if_ste.c === RCS file: /cvs/src/sys/dev/pci/if_ste.c,v retrieving revision 1.48 diff -u -p -r1.48 if_ste.c --- if_ste.c 18 Oct 2012 21:44:21 - 1.48 +++ if_ste.c 23 Nov 2012 14:07:41 - @@ -931,7 +931,7 @@ ste_attach(struct device *parent, struct ifp-if_ioctl = ste_ioctl; ifp-if_start = ste_start; ifp-if_watchdog = ste_watchdog; - ifp-if_baudrate = 1000; + ifp-if_baudrate = IF_Mbps(100); before: 1000 IF_Mbps(100): 1 Do you want to bump the default from 10Mbps to the maximum of 100Mbps in all of the Fast Ethernet drivers of this diff? The driver should probably set the baudrate based on the negotiated speed. At least this is how we do it in recent drivers. Please also note that this change does have an impact on altq in certain configurations because it will try to read ifi_baudrate in pfctl when using non-absolute interface bandwidth values. We don't really have a fixed rule for if_baudrate/ifi_baudrate. Should it show the minimum or maximum link speed? Should it show the current link speed? Using the current link speed could cause some race conditions when loading a pf ruleset with a relative altq bandwidth (like bandwidth 100%) before the link is fully negotiated. IFQ_SET_MAXLEN(ifp-if_snd, STE_TX_LIST_CNT - 1); IFQ_SET_READY(ifp-if_snd); bcopy(sc-sc_dev.dv_xname, ifp-if_xname, IFNAMSIZ); Index: if_tl.c === RCS file: /cvs/src/sys/dev/pci/if_tl.c,v retrieving revision 1.51 diff -u -p -r1.51 if_tl.c --- if_tl.c 22 Jun 2011 16:44:27 - 1.51 +++ if_tl.c 23 Nov 2012 14:07:42 - @@ -2125,7 +2125,7 @@ tl_attach(parent, self, aux) ifp-if_ioctl = tl_ioctl; ifp-if_start = tl_start; ifp-if_watchdog = tl_watchdog; - ifp-if_baudrate = 1000; + ifp-if_baudrate = IF_Mbps(100); same here... IFQ_SET_MAXLEN(ifp-if_snd, TL_TX_LIST_CNT - 1); IFQ_SET_READY(ifp-if_snd); bcopy(sc-sc_dev.dv_xname, ifp-if_xname, IFNAMSIZ); Index: if_txp.c === RCS file: /cvs/src/sys/dev/pci/if_txp.c,v retrieving revision 1.104 diff -u -p -r1.104 if_txp.c --- if_txp.c 5 Apr 2011 18:01:21 - 1.104 +++ if_txp.c 23 Nov 2012 14:07:42 - @@ -225,7 +225,7 @@ txp_attachhook(void *vsc) ifp-if_ioctl = txp_ioctl; ifp-if_start = txp_start; ifp-if_watchdog = txp_watchdog; - ifp-if_baudrate = 1000; + ifp-if_baudrate = IF_Mbps(100); I see a pattern :) IFQ_SET_MAXLEN(ifp-if_snd, TX_ENTRIES); IFQ_SET_READY(ifp-if_snd); ifp-if_capabilities = 0; Index: if_vge.c === RCS file: /cvs/src/sys/dev/pci/if_vge.c,v retrieving revision 1.51 diff -u -p -r1.51 if_vge.c --- if_vge.c 22 Jun 2011 16:44:27 - 1.51 +++ if_vge.c 23 Nov 2012 14:07:42 - @@ -787,7 +787,7 @@ vge_attach(struct device *parent, struct ifp-if_ioctl = vge_ioctl; ifp-if_start = vge_start; ifp-if_watchdog = vge_watchdog; - ifp-if_baudrate = 10; + ifp-if_baudrate = IF_Gbps(1); Ok, this is 1 Gbps in both cases. OK for this bit ;-) #ifdef VGE_JUMBO ifp-if_hardmtu = VGE_JUMBO_MTU; #endif Index: if_vr.c === RCS file: /cvs/src/sys/dev/pci/if_vr.c,v retrieving revision 1.117 diff -u -p -r1.117 if_vr.c --- if_vr.c 20 Oct 2012 16:12:22 - 1.117 +++ if_vr.c 23 Nov 2012 14:07:42 - @@ -623,7 +623,7 @@ vr_attach(struct device *parent, struct ifp-if_ioctl = vr_ioctl; ifp-if_start = vr_start; ifp-if_watchdog = vr_watchdog; - ifp-if_baudrate = 1000; + ifp-if_baudrate = IF_Mbps(100); 10 to 100 again... ifp-if_capabilities = 0; IFQ_SET_READY(ifp-if_snd); bcopy(sc-sc_dev.dv_xname, ifp-if_xname, IFNAMSIZ); Index: if_wb.c === RCS file: /cvs/src/sys/dev/pci/if_wb.c,v retrieving revision 1.49 diff -u -p -r1.49 if_wb.c --- if_wb.c 18 Oct 2012 21:44:21 - 1.49 +++ if_wb.c 23 Nov 2012 14:07:42 - @@ -794,7 +794,7 @@ wb_attach(parent, self, aux) ifp-if_ioctl = wb_ioctl; ifp-if_start = wb_start; ifp-if_watchdog = wb_watchdog; - ifp-if_baudrate = 1000; + ifp-if_baudrate = IF_Mbps(100); and here. IFQ_SET_MAXLEN(ifp-if_snd, WB_TX_LIST_CNT - 1); IFQ_SET_READY(ifp-if_snd); Reyk
Re: login_yubikey case-insensitive hex decoding
On 11/23/12 02:17, Philip Guenther wrote:
On Thu, Nov 22, 2012 at 5:28 PM, Alexander Hall alexan...@beard.se wrote:
The corresponding part in yubikey_hex_decode is for consistency and,
IMO, sanity, allowing mixed case hex strings, e.g. /var/db/yubikey/*.
Comments? OK? (Don't mess with the from-upstream-derived yubikey.c?)
...
- if ((p1 = strchr(hex_trans, *src)) == NULL)
+ if ((p1 = strchr(hex_trans, tolower(*src))) == NULL)
The argument to tolower() must be a value in the range [EOF,
0..UCHAR_MAX]. When taking characters from a char * string, you need
to cast the value to (unsigned char), ala
tolower((unsigned char)*src)
Philip Guenther
Ok... Is this documented somewhere or just common knowledge?
New diff follows, with missing include added too.
OK?
/Alexander
Index: yubikey.c
===
RCS file: /data/openbsd/cvs/src/libexec/login_yubikey/yubikey.c,v
retrieving revision 1.2
diff -u -p -r1.2 yubikey.c
--- yubikey.c 31 Jan 2012 16:58:38 - 1.2
+++ yubikey.c 23 Nov 2012 15:35:29 -
@@ -32,6 +32,8 @@
*
*/
+#include ctype.h
+
#include yubikey.h
static const uint8_t RC[] = {
@@ -252,7 +254,8 @@ yubikey_hex_decode(char *dst, const char
char *p1;
for (; *src dstSize 0; src++) {
- if ((p1 = strchr(hex_trans, *src)) == NULL)
+ p1 = strchr(hex_trans, tolower((unsigned char)*src));
+ if (p1 == NULL)
b = 0;
else
b = (char)(p1 - hex_trans);
@@ -278,7 +281,8 @@ yubikey_modhex_decode(char *dst, const c
char *p1;
for (; *src dstSize 0; src++) {
- if ((p1 = strchr(modhex_trans, *src)) == NULL)
+ p1 = strchr(modhex_trans, tolower((unsigned char)*src));
+ if (p1 == NULL)
b = 0;
else
b = (char)(p1 - modhex_trans);
Re: Display hardmtu with ifconfig hwfeatures
On Fri, Nov 23, 2012 at 04:04:20PM +, Stuart Henderson wrote:
This adds an ioctl to retrieve if_hardmtu, and adds code to
display it via ifconfig hwfeatures.
$ ifconfig em0 hwfeatures
em0: flags=8b43UP,BROADCAST,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULTICAST mtu
1500
hwfeatures=30VLAN_MTU,VLAN_HWTAGGING hardmtu=16110
lladdr f0:de:f1:f9:a7:52
priority: 0
trunk: trunkdev trunk0
media: Ethernet autoselect (100baseTX full-duplex,rxpause,txpause)
status: active
Added bonus, mention a few other existing ioctls in netintro(4).
Any comments/bikeshedding about display format/OKs?
I would replace the = after hardmtu with a single whitespace to
follow the common ifconfig style. The = is only used for flags-type
fields.
The diff looks fine to me.
Index: sys/net/if.c
===
RCS file: /cvs/src/sys/net/if.c,v
retrieving revision 1.247
diff -u -p -r1.247 if.c
--- sys/net/if.c 23 Oct 2012 17:41:00 - 1.247
+++ sys/net/if.c 23 Nov 2012 15:55:02 -
@@ -1268,6 +1268,10 @@ ifioctl(struct socket *so, u_long cmd, c
ifr-ifr_mtu = ifp-if_mtu;
break;
+ case SIOCGIFHARDMTU:
+ ifr-ifr_hardmtu = ifp-if_hardmtu;
+ break;
+
case SIOCGIFDATA:
error = copyout((caddr_t)ifp-if_data, ifr-ifr_data,
sizeof(ifp-if_data));
Index: sys/net/if.h
===
RCS file: /cvs/src/sys/net/if.h,v
retrieving revision 1.136
diff -u -p -r1.136 if.h
--- sys/net/if.h 11 Nov 2012 04:45:37 - 1.136
+++ sys/net/if.h 23 Nov 2012 15:55:02 -
@@ -639,6 +639,7 @@ structifreq {
#define ifr_flags ifr_ifru.ifru_flags /* flags */
#define ifr_metric ifr_ifru.ifru_metric/* metric */
#define ifr_mtu ifr_ifru.ifru_metric/* mtu (overload) */
+#define ifr_hardmtu ifr_ifru.ifru_metric/* hardmtu (overload) */
#define ifr_media ifr_ifru.ifru_metric/* media options
(overload) */
#define ifr_rdomainid ifr_ifru.ifru_metric/* VRF instance
(overload) */
#define ifr_dataifr_ifru.ifru_data /* for use by interface
*/
Index: sys/net/if_gre.c
===
RCS file: /cvs/src/sys/net/if_gre.c,v
retrieving revision 1.58
diff -u -p -r1.58 if_gre.c
--- sys/net/if_gre.c 14 Apr 2012 09:39:47 - 1.58
+++ sys/net/if_gre.c 23 Nov 2012 15:55:02 -
@@ -475,6 +475,9 @@ gre_ioctl(struct ifnet *ifp, u_long cmd,
case SIOCGIFMTU:
ifr-ifr_mtu = sc-sc_if.if_mtu;
break;
+ case SIOCGIFHARDMTU:
+ ifr-ifr_hardmtu = sc-sc_if.if_hardmtu;
+ break;
case SIOCADDMULTI:
case SIOCDELMULTI:
if (ifr == 0) {
Index: sys/net/if_spppsubr.c
===
RCS file: /cvs/src/sys/net/if_spppsubr.c,v
retrieving revision 1.98
diff -u -p -r1.98 if_spppsubr.c
--- sys/net/if_spppsubr.c 24 Jul 2012 15:16:20 - 1.98
+++ sys/net/if_spppsubr.c 23 Nov 2012 15:55:02 -
@@ -1117,6 +1117,11 @@ sppp_ioctl(struct ifnet *ifp, u_long cmd
ifr-ifr_mtu = ifp-if_mtu;
break;
#endif
+#ifdef SIOCGIFHARDMTU
+ case SIOCGIFHARDMTU:
+ ifr-ifr_hardmtu = ifp-if_hardmtu;
+ break;
+#endif
#ifdef SLIOCGETMTU
case SLIOCGETMTU:
*(short*)data = ifp-if_mtu;
Index: sys/sys/sockio.h
===
RCS file: /cvs/src/sys/sys/sockio.h,v
retrieving revision 1.49
diff -u -p -r1.49 sockio.h
--- sys/sys/sockio.h 26 Nov 2011 23:38:18 - 1.49
+++ sys/sys/sockio.h 23 Nov 2012 15:59:06 -
@@ -181,6 +181,8 @@
#define SIOCSETKALIVE_IOW('i', 163, struct ifkalivereq)
#define SIOCGETKALIVE_IOWR('i', 164, struct ifkalivereq)
+#define SIOCGIFHARDMTU _IOWR('i', 165, struct ifreq) /* get ifnet
hardmtu */
+
#define SIOCSVH _IOWR('i', 245, struct ifreq) /* set carp
param */
#define SIOCGVH _IOWR('i', 246, struct ifreq) /* get carp
param */
Index: sbin/ifconfig/ifconfig.c
===
RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v
retrieving revision 1.257
diff -u -p -w -r1.257 ifconfig.c
--- sbin/ifconfig/ifconfig.c 6 Sep 2012 19:41:59 - 1.257
+++ sbin/ifconfig/ifconfig.c 23 Nov 2012 16:01:07 -
@@ -4722,6 +4722,11 @@ printifhwfeatures(const char *unused, in
if (ioctl(s, SIOCGIFDATA, (caddr_t)ifr) == -1)
err(1, SIOCGIFDATA);
printb(\thwfeatures, (u_int)ifrdat.ifi_capabilities, HWFEATURESBITS);
+
+ if (ioctl(s, SIOCGIFHARDMTU,
Re: Display hardmtu with ifconfig hwfeatures
Stuart Henderson s...@spacehopper.org wrote: This adds an ioctl to retrieve if_hardmtu, and adds code to display it via ifconfig hwfeatures. I'm worried that our drivers don't set this or that the value doesn't accurately reflect the capabilities of chip/driver. -- Christian naddy Weisgerber na...@mips.inka.de
Re: VPN traffic leaks in IPv6/IPv4 dual-stack networks/hosts
On Fri, Nov 23, 2012 at 05:01:16PM +0100, Reyk Floeter wrote:
Actually, in the iked(8)/IPsec case we could even block all v6 traffic
without using PF by simply inserting a single deny flow.
For example:
# ping6 -w ff02::1%em0
# ipsecctl -vf /etc/ipsec-block.conf
flow esp out from ::/0 to ::/0 type deny
# ping6 -w ff02::1%em0
Most IPsec VPN clients could use their existing PFKEYv2 interface to
dynamically add a similar rule to their Security Policy Database. But
unfortunately, the SPD is the least portable part of PFKEYv2.
Putting it into practice, it could look like this.
iked(8) would block any IPv6 traffic by default unless an IPv6 flow is
loaded or the -6 command line flag is specified. This diff is a PoC
and definitely needs more thoughts.
Anyone?
Reyk
Index: iked.8
===
RCS file: /cvs/src/sbin/iked/iked.8,v
retrieving revision 1.10
diff -u -p -r1.10 iked.8
--- iked.8 22 Oct 2012 13:27:23 - 1.10
+++ iked.8 23 Nov 2012 17:53:15 -
@@ -23,7 +23,7 @@
.Nd Internet Key Exchange version 2 (IKEv2) daemon
.Sh SYNOPSIS
.Nm iked
-.Op Fl dnSTtv
+.Op Fl 6dnSTtv
.Oo
.Fl D Ar macro Ns = Ns Ar value
.Oc
@@ -59,6 +59,13 @@ infrastructure.
.Pp
The options are as follows:
.Bl -tag -width Ds
+.It Fl 6
+Disable automatic blocking of IPv6 traffic.
+By default,
+.Xr iked 8
+blocks any IPv6 traffic unless a flow for this address family has been
+negotiated.
+This option is used to prevent VPN traffic leakages on dual stack hosts.
.It Fl D Ar macro Ns = Ns Ar value
Define
.Ar macro
Index: iked.c
===
RCS file: /cvs/src/sbin/iked/iked.c,v
retrieving revision 1.13
diff -u -p -r1.13 iked.c
--- iked.c 22 Oct 2012 10:25:17 - 1.13
+++ iked.c 23 Nov 2012 17:53:15 -
@@ -65,7 +65,7 @@ usage(void)
{
extern char *__progname;
- fprintf(stderr, usage: %s [-dnSTtv] [-D macro=value]
+ fprintf(stderr, usage: %s [-6dnSTtv] [-D macro=value]
[-f file]\n, __progname);
exit(1);
}
@@ -82,8 +82,11 @@ main(int argc, char *argv[])
log_init(1);
- while ((c = getopt(argc, argv, dD:nf:vSTt)) != -1) {
+ while ((c = getopt(argc, argv, 6dD:nf:vSTt)) != -1) {
switch (c) {
+ case '6':
+ opts |= IKED_OPT_NOIPV6BLOCKING;
+ break;
case 'd':
debug++;
break;
Index: iked.h
===
RCS file: /cvs/src/sbin/iked/iked.h,v
retrieving revision 1.54
diff -u -p -r1.54 iked.h
--- iked.h 22 Oct 2012 10:25:17 - 1.54
+++ iked.h 23 Nov 2012 17:53:16 -
@@ -141,6 +141,7 @@ struct iked_flow {
u_int8_t flow_saproto;
u_int8_t flow_ipproto;
+ u_int8_t flow_type;
struct iked_id *flow_srcid;
struct iked_id *flow_dstid;
@@ -762,6 +763,7 @@ int eap_parse(struct iked *, struct ike
int pfkey_couple(int, struct iked_sas *, int);
int pfkey_flow_add(int fd, struct iked_flow *);
int pfkey_flow_delete(int fd, struct iked_flow *);
+int pfkey_block(int, int, u_int);
int pfkey_sa_init(int, struct iked_childsa *, u_int32_t *);
int pfkey_sa_add(int, struct iked_childsa *, struct iked_childsa *);
int pfkey_sa_delete(int, struct iked_childsa *);
Index: pfkey.c
===
RCS file: /cvs/src/sbin/iked/pfkey.c,v
retrieving revision 1.20
diff -u -p -r1.20 pfkey.c
--- pfkey.c 23 Oct 2012 14:40:14 - 1.20
+++ pfkey.c 23 Nov 2012 17:53:18 -
@@ -48,7 +48,9 @@
static u_int32_t sadb_msg_seq = 0;
static u_int sadb_decoupled = 0;
+static u_int sadb_ipv6refcnt = 0;
+static int pfkey_blockipv6 = 0;
static struct event pfkey_timer_ev;
static struct timeval pfkey_timer_tv;
@@ -247,7 +249,7 @@ pfkey_flow(int sd, u_int8_t satype, u_in
bzero(slocal, sizeof(slocal));
bzero(speer, sizeof(speer));
- if (action != SADB_X_DELFLOW) {
+ if (action != SADB_X_DELFLOW flow-flow_local != NULL) {
memcpy(slocal, flow-flow_local-addr, sizeof(slocal));
socket_af((struct sockaddr *)slocal, 0);
@@ -268,8 +270,9 @@ pfkey_flow(int sd, u_int8_t satype, u_in
sa_flowtype.sadb_protocol_len = sizeof(sa_flowtype) / 8;
sa_flowtype.sadb_protocol_direction = flow-flow_dir;
sa_flowtype.sadb_protocol_proto =
- flow-flow_dir == IPSP_DIRECTION_IN ?
- SADB_X_FLOW_TYPE_USE : SADB_X_FLOW_TYPE_REQUIRE;
+ flow-flow_type ? flow-flow_type :
+ (flow-flow_dir == IPSP_DIRECTION_IN ?
+ SADB_X_FLOW_TYPE_USE : SADB_X_FLOW_TYPE_REQUIRE);
bzero(sa_protocol,
Re: Display hardmtu with ifconfig hwfeatures
On Fri, Nov 23, 2012 at 05:46:27PM +, Christian Weisgerber wrote: Stuart Henderson s...@spacehopper.org wrote: This adds an ioctl to retrieve if_hardmtu, and adds code to display it via ifconfig hwfeatures. I'm worried that our drivers don't set this or that the value doesn't accurately reflect the capabilities of chip/driver. If the driver doesn't set it, if_hardmtu defaults to 1500. I think this should be fine. But the if_hardmtu is really just a guess or a driver limit, because sometimes the chipset specs lie about the real limit (it is either more or even less) or the if_hardmtu is based on driver buffer sizes like MCLBYTES - ETHER_HDR_LEN - ETHER_CRC_LEN. But this should be fine as well if we just see it as what the driver manages to use as a hard limit. Reyk
Re: Display hardmtu with ifconfig hwfeatures
On 2012/11/23 17:46, Christian Weisgerber wrote: Stuart Henderson s...@spacehopper.org wrote: This adds an ioctl to retrieve if_hardmtu, and adds code to display it via ifconfig hwfeatures. I'm worried that our drivers don't set this or that the value doesn't accurately reflect the capabilities of chip/driver. In some cases (especially 100Mb chips which support baby jumbos) I know that they don't reflect the capability of the chip. For ethernet devices, except in the case of oce(4), if the driver doesn't set hardmtu, the mtu can't be raised above ETHER_MTU. (in most cases this is checked in ether_subr.c; oce and ix have their own check in the driver). BTW my use cases for this are, - showing the maximum size I can use on pfsync between two directly-connected machines - identifying interface types that I can use to run tunnels/pppoe containing packets with 1500 MTU It's possible to check driver source for this of course, but in some cases like bge(4) it needs a bit of digging to work out which chip family you have.
Re: Display hardmtu with ifconfig hwfeatures
On Fri, Nov 23, 2012 at 5:16 PM, Reyk Floeter r...@openbsd.org wrote: On Fri, Nov 23, 2012 at 04:04:20PM +, Stuart Henderson wrote: This adds an ioctl to retrieve if_hardmtu, and adds code to display it via ifconfig hwfeatures. $ ifconfig em0 hwfeatures em0: flags=8b43UP,BROADCAST,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULTICAST mtu 1500 hwfeatures=30VLAN_MTU,VLAN_HWTAGGING hardmtu=16110 lladdr f0:de:f1:f9:a7:52 priority: 0 trunk: trunkdev trunk0 media: Ethernet autoselect (100baseTX full-duplex,rxpause,txpause) status: active Added bonus, mention a few other existing ioctls in netintro(4). Any comments/bikeshedding about display format/OKs? I would replace the = after hardmtu with a single whitespace to follow the common ifconfig style. The = is only used for flags-type fields. The diff looks fine to me. funny enough there's no equal sign in the original diff (: ok mikeb
Re: powerpc: Keep track of uncached managed memory
Date: Fri, 23 Nov 2012 12:23:19 +0100 From: Martin Pieuchot mpieuc...@nolizard.org Ok, a bit of explanation first. On macppc because the AGP chips do not translate pages, the kernel and the applications have access to the AGP memory regions through standard mappings. Because these regions are mean to share commands and data and the AGP bridges are not cache-coherent, they are mapped NOCACHE by the appleagp driver. However in the case of the dri/drm infrastructure these memory regions are first allocated and mapped by the agp driver then mmap'ed by the userland graphic driver. Martin, I probably should have asked this earlier, but how is this memory mapped by the userland graphics driver? Is that done by opening /dev/agp and then calling mmap(2) on the filedescriptor? If so, perhaps a better approach would be to have the agp mmap function return a PMAP_NC bit in the lower bits of the physical address. This is what sparc and sparc64 do.
Re: login_yubikey case-insensitive hex decoding
On Fri, 23 Nov 2012, Alexander Hall wrote: On 11/23/12 02:17, Philip Guenther wrote: ... The argument to tolower() must be a value in the range [EOF, 0..UCHAR_MAX]. When taking characters from a char * string, you need to cast the value to (unsigned char), ala tolower((unsigned char)*src) Ok... Is this documented somewhere or just common knowledge? It's a property of all the ctype.h functions, which we've documented for the is* functions in the CAVEATS section of their pages; here's the diff to add the matching statement to tolower(3) and toupper(3). Philip Index: gen/tolower.3 === RCS file: /cvs/src/lib/libc/gen/tolower.3,v retrieving revision 1.11 diff -u -p -r1.11 tolower.3 --- gen/tolower.3 31 May 2007 19:19:29 - 1.11 +++ gen/tolower.3 23 Nov 2012 22:12:21 - @@ -99,3 +99,11 @@ and .Fn _tolower functions conform to .St -ansiC . +.Sh CAVEATS +The argument to +.Nm +must be +.Dv EOF +or representable as an +.Li unsigned char ; +otherwise, the result is undefined. Index: gen/toupper.3 === RCS file: /cvs/src/lib/libc/gen/toupper.3,v retrieving revision 1.13 diff -u -p -r1.13 toupper.3 --- gen/toupper.3 31 May 2007 19:19:29 - 1.13 +++ gen/toupper.3 23 Nov 2012 22:12:21 - @@ -97,3 +97,11 @@ The .Fn toupper function conforms to .St -ansiC . +.Sh CAVEATS +The argument to +.Nm +must be +.Dv EOF +or representable as an +.Li unsigned char ; +otherwise, the result is undefined.
