Bug#672232: [pkg-dhcp-devel] Bug#672232: Re isc-dhcp-client: method to ignore settings provided by the server
control: tag -1 upstream control: tag -1 -security control: forwarded -1 ISC bug #35631 control: retitle -1 dhclient adopts dhcp server's settings despite them not being "request"ed On Sun, Nov 29, 2015 at 2:42 PM, Christoph Anton Mitterer wrote: > supersede isn't really of any help here since a) it doesn't seem to > properly work in all places, and b) one cannot use it do just "unset" a > server provided value (i.e. using the empty string or so doesn't work). The syntax may very well be a bit odd, but a few minutes of intellectual poking with supersede leads to a simple solution for all of the problems mentioned so far. That is left as an exercise for the astute reader. Please feel free to add the security tag once your request for a CVE id goes through. For now, since there are simple workarounds, and given that this is an upstream design flaw rather than a Debian-specific issue, further effort on solving it should go there. Good luck! Best wishes, Mike
Bug#672232: [pkg-dhcp-devel] Bug#672232: Re isc-dhcp-client: method to ignore settings provided by the server
On Sun, 2015-11-29 at 17:36 -0500, Michael Gilbert wrote: > control: tag -1 upstream > control: tag -1 -security > control: forwarded -1 ISC bug #35631 > control: retitle -1 dhclient adopts dhcp server's settings despite > them not being "request"ed Working with you is always uhm... like Christmas... o.O > The syntax may very well be a bit odd, but a few minutes of > intellectual poking with supersede leads to a simple solution for all > of the problems mentioned so far. That is left as an exercise for > the > astute reader. The solution can't be to use supersede, as this requires one to actually set a secure/usable value. For many there may not be a value which one desires to set (e.g. dns search)... for others, e.g. ntp-servers the best one could do is to use localhost, which is however not working either, as software then actually tries to query NTP at localhost. > For now, since there are simple workarounds, and > given that this is an upstream design flaw rather than a > Debian-specific issue, further effort on solving it should go there. I never said it's a debian specific bug, but since upstream hides behind not even having a proper bugtracker its probably pointless to have one further iteration of pressing there. Effectively only the distros would be powerful enough to build up the necessary pressure for upstream to do something. Given that you're from the security team, I guess removing the security tag means effectively that the security denies any issue that upstream doesn't want to deal with to be a security issue. And further, an attack vector that, as shown above with the expiry of X509 certs, can be clearly any extremely simply be used isn't considered worth to be fixed by Debian? Just simulated that before... set up a local forged NTP server, sent it via dhcp, when a node in the network reboots at least ntpdate takes this up and sets any arbitrary date... voila... one can use expired certs again.. Security-ignorance at it's finest o.O smime.p7s Description: S/MIME cryptographic signature
Bug#672232: Re isc-dhcp-client: method to ignore settings provided by the server
Control: severity -1 important Control: tags -1 = security Hey. Still cannot believe that this hasn't been dealt with after so many years... o.O As explained previously, dhclient doesn't seem to allow to disable certain security relevant options from being received (and configured) from the server. For example, even when setting: request subnet-mask, broadcast-address, time-offset, routers, domain-name-servers, dhcp6.name-servers, dhcp6.fqdn, netbios-name-servers, netbios-scope, interface-mtu, rfc3442-classless-static-routes; It would still take ntp servers, domain search path, etc. from the server if that offers it. These values however are quite security critical. A rogue DHCP server may direct any client (e.g. a notebook connected to any public network) to use a evil NTP server, which could ultimately lead to a wrong system time being set, which in turn could lead to expired certificates, software updates, etc. being used. Similar, playing around with the domain search path could trick a system into using/trusting/etc. the wrong names. supersede isn't really of any help here since a) it doesn't seem to properly work in all places, and b) one cannot use it do just "unset" a server provided value (i.e. using the empty string or so doesn't work). I just stumbled over this issue again, when we observed a successful attack on two of our institutes notebooks. Turned out in the end that their time/date must have been influenced maliciously... Michael, I've seen you've removed important, security and added unreproducible without any further explanations... o.O Adding these back, as the above examples clearly show that this can be exploited,... further removing unreproducible as it was even confirmed before by Felix and reproduction seems straight-forward. Cheers, Chris.
Bug#672232: [pkg-dhcp-devel] Bug#672232: Bug#672232: Re isc-dhcp-client: method to ignore settings provided by the server
On Sun, 2015-11-29 at 18:42 -0500, Michael Gilbert wrote: > Seriously, just stop. The never-ending negativity helps no one. Uhm... IIRC it was you who publicly denounced me on d-d and some other places. When I wrote you a mail later, trying to talk about that behaviour, I got no replay... so I don't think I'm negative but rather realistic. > Absolutely not the point. You apparently couldn't figure out > supersede and yet it is trivially figure outable. That is all that > particular paragraph stated. I don't understand what you mean by " You apparently couldn't figure out supersede" I even wrote about it in message #31... o.O > > For many there may not be a value which one desires to set (e.g. > > dns > > search)... for others, e.g. ntp-servers the best one could do is to > > use > > localhost, which is however not working either, as software then > > actually tries to query NTP at localhost. > > What about an ntp pool that is already somehow marginally trusted, > like the debian ones used by default in the ntp package? Left aside, that NTP by itself isn't secured in any way (i.e. cryptographically)... people could in principle set up a VPN to a NTP server they know they can trust. But even if that isn't done, I don't see how using the debian pool helps. If the DHCP advertises it's own evil NTP server, than that will be used. At least ifupdown does so (network manager interestingly seems to ignore that part of DHCP). > The point was missed yet again. If an issue affects all of the open > source community need to be defended in front of the entire open > source community. Sure it does affect the whole community. But as I've said, upstream didn't react back then when I originally reported that bug. I did report it once again with more clear exploitation examples.. let's see what comes up, though I have little hope. The best one could do right now (except waiting for a NTP successor) is do confine the problems a bit at the DHCP level. And for attacks based on mangling around with the DNS search list, the proper solution is at the DHCP client, it simply shouldn't accept it (same for several other parameters). And I hope I don't need to explain, that a sane security policy is to only whitelist those properties one really wants and not to blacklist those one doesn't want. > > Given that you're from the security team, I guess removing the > > security > > tag means effectively that the security denies any issue that > > upstream > > doesn't want to deal with to be a security issue. > > No, absolutely not, and point yet again completely missed. Then it makes no sense to have the tag and severity removed. As my example showed (and that was just one using NTP), most kinds of crypto/security system that somehow depend on time, may be probably attacked by injecting bad time servers to the client. So it definitely has a high impact and it is security related. Taking the definition from https://www.debian.org/Bugs/Developer#tags >security > This bug describes a security problem in a package (e.g., bad > permissions allowing access to data that shouldn't be accessible; > buffer overruns allowing people to control a system in ways they > shouldn't be able to; denial of service attacks that should be > fixed, etc). Most security bugs should also be set at critical or > grave severity. This doesn't mention that it only applies to issues at Debian, or to issues that can easily be fixed. It also doesn't state that it would apply to code security issues (i.e. buffer overruns or so). > If you are in fact capable of defending your claims in front of > peers, > then let's absolutely treat this as a security concern. If not, then > I have no interest in being the lackey dealing with the never-ending > insult and incompetence. And where would I have insulted you? Which is quite some irony given that you describe me at the same sentence with incompetence... The only thing negative I can find in my mail is "Security-ignorance at it's finest o.O" which simply describes that fact that this issue is apparently ignored in Debian (based already on the fact that the security-tag is removed). It doesn't claim anything about you, whether you're smart, supid, friendly, hostile or anything else. > Good work, should be excellent justification for your CVE request > (with real details of course)! AFAIU, people couldn't just directly request CVEs, can they? I though that need to happen via a CNA, which Debian, to my knowledge, was one. Anyway. I wasn't aware that only security issues with a CVE may be recorded and marked as such in the Debian BTS. And countless other bugs, which are either marked security or upstream seem to confirm that this is in fact not the case. smime.p7s Description: S/MIME cryptographic signature
Bug#672232: [pkg-dhcp-devel] Bug#672232: Bug#672232: Bug#672232: Re isc-dhcp-client: method to ignore settings provided by the server
On Sun, Nov 29, 2015 at 9:21 PM, Christoph Anton Mitterer wrote: > On Sun, 2015-11-29 at 19:30 -0500, Michael Gilbert wrote: >> Then you shouldn't use the Debian ntp package or any other Debian >> package at all for that matter. > Then I guess one can also close this bug as wontfix, suggesting any > people not to use such packages or try to improve the situation within > Debian. To interpret that correctly, you need the prior context. I'm wasting my time explaining this, but here goes. The point was that if you're unwilling to trust the debian ntp pool, then you should also mistrust the debian ntp package which by default chose that "evil" debian ntp pool, and if you're so inclined to not trust debian packages like ntp, then you might as well distrust all debian packages, and give up. It's called reductio ad absurdum. Please try to keep up. >> Like I said, the security tag is for now removed because I am not >> going to deal with it as a security issue until you defend it to your >> peers. > Who are my peers? How can I possibly make it any clearer? Go to oss-sec. Those are your peers. Why is this so difficult? >> I am not interested in looking at it because I am far beyond >> my tolerance threshold with your behavior. > "Your tolerance treshold" ... funny... but even if I'd be a jerk, other > users will thank you for hiding the security issue away by removing > tag, just because you don't like me. I've clearly described how to get your precious merit badge back. Why are you unwilling to defend yourself against your peers? >> Clearly prior behavior plays a huge role here. > Well the only other > matter I can remember where we have had more direct interaction was > about the blob issues in chromium. And you got that absolutely wrong too. The chromium packages were not built with native client, so the native client blob was totally inert. > Anyway... since apparently this won't get solved, may I suggest that we > close the bug as wontfix? No, go to oss-sec and make your case. You can earn your precious trivial security tag by doing real quality analysis and defensible work. Best wishes, Mike
Bug#672232: [pkg-dhcp-devel] Bug#672232: Bug#672232: Re isc-dhcp-client: method to ignore settings provided by the server
On Sun, Nov 29, 2015 at 7:07 PM, Christoph Anton Mitterer wrote: > Left aside, that NTP by itself isn't secured in any way (i.e. > cryptographically)... people could in principle set up a VPN to a NTP > server they know they can trust. Please go write SecureNTP then. > But even if that isn't done, I don't see how using the debian pool > helps. > If the DHCP advertises it's own evil NTP server, than that will be > used. At least ifupdown does so (network manager interestingly seems to > ignore that part of DHCP). Then you shouldn't use the Debian ntp package or any other Debian package at all for that matter. > This doesn't mention that it only applies to issues at Debian, or to > issues that can easily be fixed. > It also doesn't state that it would apply to code security issues (i.e. > buffer overruns or so). Like I said, the security tag is for now removed because I am not going to deal with it as a security issue until you defend it to your peers. I am not interested in looking at it because I am far beyond my tolerance threshold with your behavior. It is up to you to change that. > The only thing negative I can find in my mail is > "Security-ignorance at it's finest o.O" > which simply describes that fact that this issue is apparently ignored > in Debian (based already on the fact that the security-tag is removed). > It doesn't claim anything about you, whether you're smart, supid, > friendly, hostile or anything else. Clearly prior behavior plays a huge role here. >> Good work, should be excellent justification for your CVE request >> (with real details of course)! > AFAIU, people couldn't just directly request CVEs, can they? > I though that need to happen via a CNA, which Debian, to my knowledge, > was one. CNA's only issue ids for non-public issues. Absolutely anyone can and should send CVE requests to oss-sec for issues that are already public. > Anyway. I wasn't aware that only security issues with a CVE may be > recorded and marked as such in the Debian BTS. That is not true. But like I said, I am not interested in dealing with your negativity any more, so please make your case to others. Best wishes, Mike
Bug#672232: [pkg-dhcp-devel] Bug#672232: Bug#672232: Re isc-dhcp-client: method to ignore settings provided by the server
On Sun, 2015-11-29 at 19:30 -0500, Michael Gilbert wrote: > Then you shouldn't use the Debian ntp package or any other Debian > package at all for that matter. Then I guess one can also close this bug as wontfix, suggesting any people not to use such packages or try to improve the situation within Debian. > Like I said, the security tag is for now removed because I am not > going to deal with it as a security issue until you defend it to your > peers. Who are my peers? I described the issue, no one brought up a valid argument why this cannot be abused... what else do you want? A paper, peer-reviewed and published in Nature? > I am not interested in looking at it because I am far beyond > my tolerance threshold with your behavior. "Your tolerance treshold" ... funny... but even if I'd be a jerk, other users will thank you for hiding the security issue away by removing tag, just because you don't like me. > It is up to you to change that. As said before, I wrote you a mail when you said some unpleasant things about me several times, but didn't get any reply... The ball wouldn't be in my half of the fiel. > Clearly prior behavior plays a huge role here. Well the only other matter I can remember where we have had more direct interaction was about the blob issues in chromium. Apparently these are there and not just made up in my mind, others have reported it as well and even when that specific last case where I was involved was allegedly not possible to abuse, I still don't see a crime in reporting such cases and having it cleared up. Some people may not worry about software shipping blobs, or at least having framworks in place to download such (like Firefox does with OpenH264),... other however do and their case isn't less valid. I'm afraid that others took that ticket up and made some big news out of it even if it didn't turn out to be a big issue,... but that isn't my fault. So other than - I don't know the exact words you accused me last time - "not contributing code" or something like this... I don't see much wrong behaviour on my side. Anyway... since apparently this won't get solved, may I suggest that we close the bug as wontfix? Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#672232: [pkg-dhcp-devel] Bug#672232: Bug#672232: Re isc-dhcp-client: method to ignore settings provided by the server
On Sun, Nov 29, 2015 at 5:56 PM, Christoph Anton Mitterer wrote: > Working with you is always uhm... like Christmas... o.O Seriously, just stop. The never-ending negativity helps no one. >> The syntax may very well be a bit odd, but a few minutes of >> intellectual poking with supersede leads to a simple solution for all >> of the problems mentioned so far. That is left as an exercise for >> the >> astute reader. > > The solution can't be to use supersede, as this requires one to > actually set a secure/usable value. Absolutely not the point. You apparently couldn't figure out supersede and yet it is trivially figure outable. That is all that particular paragraph stated. > For many there may not be a value which one desires to set (e.g. dns > search)... for others, e.g. ntp-servers the best one could do is to use > localhost, which is however not working either, as software then > actually tries to query NTP at localhost. What about an ntp pool that is already somehow marginally trusted, like the debian ones used by default in the ntp package? > For now, since there are simple workarounds, and >> given that this is an upstream design flaw rather than a >> Debian-specific issue, further effort on solving it should go there. > I never said it's a debian specific bug, but since upstream hides > behind not even having a proper bugtracker its probably pointless to > have one further iteration of pressing there. The point was missed yet again. If an issue affects all of the open source community need to be defended in front of the entire open source community. > Given that you're from the security team, I guess removing the security > tag means effectively that the security denies any issue that upstream > doesn't want to deal with to be a security issue. No, absolutely not, and point yet again completely missed. If you are in fact capable of defending your claims in front of peers, then let's absolutely treat this as a security concern. If not, then I have no interest in being the lackey dealing with the never-ending insult and incompetence. > Just simulated that before... set up a local forged NTP server, sent it > via dhcp, when a node in the network reboots at least ntpdate takes > this up and sets any arbitrary date... voila... one can use expired > certs again.. Good work, should be excellent justification for your CVE request (with real details of course)! Best wishes, Mike
