[pkg-dhcp-devel] Bug#672232: Bug#672232: Bug#672232: Re isc-dhcp-client: method to ignore settings provided by the server

[Christoph Anton Mitterer]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3575 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-dhcp-devel/attachments/20151130/4cd09258/attachment.bin>