Re: NTP
On Fri, 19 Dec 2014 18:22:47 -0700 Theo de Raadt dera...@cvs.openbsd.org wrote: openntpd is not vulnerable. Depends on which vulnerability you mean. It is probably vulnerable to this one: http://zero-entropy.de/autokey_analysis.pdf (tl;dr ntp authentication is not secure) And it is probably vulnerable to this: https://github.com/PentesterES/Delorean (tl;dr Man-in-the-Middle) ntp is not secure. openntpd is a more secure implementation of a protocol that is not secure by design. -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 pgppRon8i_0_S.pgp Description: OpenPGP digital signature
Re: NTP
On 2014 Dec 20 (Sat) at 12:42:52 +0100 (+0100), Hanno B??ck wrote: :On Fri, 19 Dec 2014 18:22:47 -0700 :Theo de Raadt dera...@cvs.openbsd.org wrote: : : openntpd is not vulnerable. : :Depends on which vulnerability you mean. : :It is probably vulnerable to this one: :http://zero-entropy.de/autokey_analysis.pdf :(tl;dr ntp authentication is not secure) : OpenNTPd does not do auth at all. :And it is probably vulnerable to this: :https://github.com/PentesterES/Delorean :(tl;dr Man-in-the-Middle) : OpenNTPd embeds random cookies into several fields of the ntp packet, the server is required to copy them back into the reply, and the client checks them upon receiving it. Not as vulnerable as you think. :ntp is not secure. openntpd is a more secure implementation of a :protocol that is not secure by design. : :-- :Hanno B??ck :http://hboeck.de/ : :mail/jabber: ha...@hboeck.de :GPG: BBB51E42 -- If a President doesn't do it to his wife, he'll do it to his country.
Re: Fix upd(4) sensor refresh
On Fri, Dec 19, 2014 at 8:55 AM, Martin Pieuchot mpieuc...@nolizard.org wrote: On 19/12/14(Fri) 08:04, David Higgs wrote: Split upd_update_sensors() behavior to gather all values prior to updating sensor contents. Because sensors were updated in report_ID order, it could take multiple passes of upd_refresh() to update some sensors. Specifically, battery-related sensors prior to a change in BatteryPresent would be stale/incorrect until the 2nd call to upd_refresh(). Also, change a confusing DPRINTF of report_ID from un-prefixed hex to decimal, to be consistent. What you're saying is that querying HUB_BATTERY_PRESENT after 6 sensors that depend on its value does not make sense, right? Correct. Well in this case I don't think that sensors should be queried in reportID order. I even don't think that sensors should be queried at all if we're going to discard the result anyway. It might not matter that much right now, but if the number of queried sensors grow s significantly we might end up waiting a lot of time in upd_refresh() prior to updating anything. Querying by report_ID minimizes the number of requests, because multiple sensors can be batched into the same report_ID. I don't know if there are any rules that determine how items are batched, so there may be pathologically bad results. This fix is needed for future improvements, where output or behavior of certain sensors depends on the current value of more than one report (e.g. RemainingCapacity should actually depend on CapacityMode). But do you need to read the value of CapacityMode more than once, at the begging or when you modify it? True. CapacityMode shouldn't automatically change and can be read once (and/or maybe updated) at attach-time. I see no reason to expose this setting for users to change. Anyway, when we discussed that with Andre, I suggested to have a table containing all sensors depending on an other one. This way you can start by querying HUB_BATTERY_PRESENT and if it is present, query the others. Another advantage is that it will simplify the code because all the sensors in a table will be in the same page. This sounds good. I will revisit the Power/Battery spec and see what future sensors might require dependent behavior. Since you're doing some great job with upd(4), here's another idea. Did you consider updating the values of the sensors via an asynchronous function and a callback? This way the thread does not need to way for the previous queries. That would involve adding a new function, let's say uhidev_get_report_async() that takes a custom callback since there's no such API for the moment. This sounds like a good idea, but batched report_ID values can produce redundant USB queries or will require additional logic/caching to minimize this redundancy. I'm new to all this, and am not sure how to decide which trade-offs to make. Thanks. --david
support WCCPv2 in gre(4)
This diff allows us to set net.inet.gre.wccp sysctl to 2, in which case gre(4) will skip the WCCPv2 redirect header, allowing us to handle the packet in the same way as WCCPv1. Squid knows how to set up the WCCPv2 session with the Cisco and handles transparent HTTP proxying, use PF divert the traffic into Squid's intercept port (or with relayd, use 'forward to destination') Tested on amd64 with a Cisco ASA 5520. More magic (perhaps in PF) would be needed to actually interpret the redirect header and fully handle the WCCPv2 protocol. Index: share/man/man4/gre.4 === RCS file: /cvs/src/share/man/man4/gre.4,v retrieving revision 1.39 diff -u -p -u -r1.39 gre.4 --- share/man/man4/gre.419 Oct 2013 16:53:15 - 1.39 +++ share/man/man4/gre.420 Dec 2014 11:56:25 - @@ -54,7 +54,10 @@ variables respectively in .It Va net.inet.gre.allow Allow GRE packets in and out of the system. .It Va net.inet.gre.wccp -Allow WCCPv1-style GRE packets into the system (depends on the above). +Set to 1 to allow WCCPv1-style GRE packets into the system, +set to 2 to handle the the packets as WCCPv2-style GRE, truncating +the redirect header. +This variable depends on the above. .It Va net.inet.mobileip.allow Allow MobileIP packets in and out of the system. .El @@ -235,8 +238,8 @@ The kernel must be set to forward datagr option to .Xr sysctl 8 . .Pp -The GRE interface will accept WCCPv1-style GRE encapsulated packets -from a Cisco router. +The GRE interface will accept WCCPv1-style or WWCPv2-style GRE +encapsulated packets from a Cisco router. Some magic with the packet filter configuration and a caching proxy like squid are needed to do anything useful with these packets. @@ -292,6 +295,5 @@ these packets. .Sh BUGS GRE RFC not yet fully implemented (no GRE options). .Pp -For the WCCP GRE encapsulated packets we can only reliably accept -WCCPv1 format; WCCPv2 formatted packets add another header which will -skew the decode, and results are not defined (i.e. don't do WCCPv2). +For WCCPv2 GRE encapsulated packets we don't handle the redirect +header, but simply skip it. Index: sys/netinet/ip_gre.c === RCS file: /cvs/src/sys/netinet/ip_gre.c,v retrieving revision 1.52 diff -u -p -u -r1.52 ip_gre.c --- sys/netinet/ip_gre.c19 Dec 2014 17:14:40 - 1.52 +++ sys/netinet/ip_gre.c20 Dec 2014 11:56:25 - @@ -145,14 +145,22 @@ gre_input2(struct mbuf *m, int hlen, u_c * GRE tunnel is precisely a IP-in-GRE tunnel that differs * only in its protocol number. At least, it works for me. * -* The Internet Draft can be found if you look for +* The Internet Drafts can be found if you look for +* the following: * draft-forster-wrec-wccp-v1-00.txt +* draft-wilson-wrec-wccp-v2-01.txt * * So yes, we're doing a fall-through (unless, of course, * net.inet.gre.wccp is 0). */ if (!gre_wccp) return (0); + /* +* For WCCPv2, additionally skip the 4 byte +* redirect header. +*/ + if (gre_wccp == 2) + hlen += 4; case ETHERTYPE_IP: /* shouldn't need a schednetisr(), as */ ifq = ipintrq; /* we are in ip_input */ af = AF_INET;
Re: NTP
On 2014-12-20, Peter Hessler phess...@theapt.org wrote: :And it is probably vulnerable to this: :https://github.com/PentesterES/Delorean :(tl;dr Man-in-the-Middle) OpenNTPd embeds random cookies into several fields of the ntp packet, the server is required to copy them back into the reply, and the client checks them upon receiving it. Not as vulnerable as you think. Perfectly vulnerable to MitM. It just protects against random hosts spraying you with bogus packets. If you need authenticated NTP, use IPsec. While there, you'll want to authenticate nameserver replies, too. -- Christian naddy Weisgerber na...@mips.inka.de
Re: pstat segfault
On Fri, Dec 19, 2014 at 20:56, Fred wrote: On 12/19/14 18:12, Ted Unangst wrote: On Fri, Dec 19, 2014 at 13:04, Stuart Cassoff wrote: On 12/19/14 07:18, Stuart Cassoff wrote: $ pstat -T 221/7030 open files Segmentation fault I suppose more info from me is desired. I think that was sufficient. It should be fixed now. Hi Ted, It's fixed, but if I run pstat as an ordinary user I get: port:fred /usr/src/usr.sbin/pstat ./pstat -T pstat: kvm_openfiles: /dev/mem: Permission denied As expected. pstat needs to be setgid.
Re: Dell R630 high interrupts on acpi0
On Fri, Dec 19, 2014 at 02:58:13PM +0100, Mark Kettenis wrote: Date: Fri, 19 Dec 2014 23:41:56 +1000 From: Jonathan Matthew jonat...@d14n.org On Thu, Dec 18, 2014 at 11:14:54PM +0100, Frederic Nowak wrote: Hi! The diff for extracting memory ranges from ACPI was obviously not tested with ACPI disabled...so we definitely have to check if the values in pcimem_range make some sense. The diff below now uses the old values in case ACPI is disabled or does not return valid values. I hope this is somewhat interesting for someone else as well :) Please let me know if this is just noise or if there is anything else I am missing. This looks like the right direction, except I think we only really want to use the ACPI range information to add new ranges to the existing one that covers the 36-bit address space, rather than relying on it for everything. No point relying on the ACPI stuff being correct if we don't need to. I hacked this around a bit today and ended up with the diff below. This only deals with ranges outside the 36-bit space, so it makes no difference on most machines, and on the r630 that needs it, it adds two ranges, 0x0300 to 0x033F and 0x0340 to 0x037F. This is going in the right direction. The way I designed things though was that the acpi code would build up the complete extent purely from information provided by _CRS, and set pcimem_ex before pci_init_extents() gets called. Ah, OK, I'll make it do that instead. I probably won't be able to work on this for the next week or so, but I'll pick it up again after that.
