[Dnsmasq-discuss] [PATCH] Another regression from v2.83 on bound interfaces

Simon Kelley simon at thekelleys.org.uk
Fri Mar 12 23:54:07 UTC 2021


So, networkmanager is specifying a source address or interface with its
servers? Slightly worrying that that inhibits random ports and reduces
security anyway. I don't think your patch makes it any worse.

I think it's possible to iterate over all the servers that a query could
have been sent to using only forward->sentto as input, which would give
the set of sfds a query would have been sent to and is a more
conservative test than yours. I think yours is fine, but iterating over
the possible servers saves us trying to prove that!


<FX: furious typing>

I came up with the attached patch. It compiles, but is completely untested.

Simon.

On 10/03/2021 10:22, Petr Menšík wrote:
> It was found this behaviour does not depend on specific kernel version,
> but on sysctl net.ipv4.conf.all.rp_filter configured by default on the
> system.
> 
> It works with values 0 and 2 (2 is used on Fedora), but does not work on
> RHEL 7 or RHEL 8 with value=1.
> 
> Of course it is important to take both all and interface specific value
> into account. Evaluated value is take from rp_filter =
> max(net.ipv4.conf.$IFACE.rp_filter,net.ipv4.conf.all.rp_filter)
> 
> If only bound interfaces are configured and rp_filter==1, then current
> resolution would work only on the last interface. If active route is on
> the first interface, it just would not work at all.
> 
> On my test machine, resolution were saved by IPv6 resolution received
> via router advertisement. It does not use bound socket and therefore
> worked with rp filter.
> 
> On 3/9/21 1:25 AM, Petr Menšík wrote:
>> Hi Simon,
>>
>> Another issue was reported on RHEL7 dnsmasq 2.76[1] after CVE fixes were
>> backported. I think this issue is still present on current version as
>> well, it is just not as severe as on RHEL7 kernel
>> 3.10.0-1160.21.1.el7.x86_64.
>>
>> It happens when dnsmasq is used in dns=dnsmasq under Network Manager. It
>> configures then separate servers for each interface and prepares socket
>> for outgoing requests. Because of changes to harden accepted replies
>> only from correct socket, it would accept only response from the last
>> server with bound socket. When a laptop is connected with both
>> interfaces, it stops resolution altogether. On RHEL7, for yet unknown
>> reason it blocks reply over wifi device, it never reaches the socket of
>> dnsmasq (tested with strace). Reply over ethernet arrives, but because
>> frec->sentto->sfd->fd does not match attempt last sent over wifi, it is
>> ignored.
>>
>> Specific issue prevents complete resolution, once both devices are
>> connected. When only one of them is connected, resolution work both over
>> wifi and ethernet separately.
>>
>> On RHEL8 kernel 4.18.0-295.el8.x86_64 receiving over wifi still works,
>> so it does not break resolution. When I used iptables to block incoming
>> responses over wifi, it failed to switch to ethernet even on v2.84. It
>> is just saved by the last working interface this time. If that breaks,
>> it breaks completely. The same on Fedora 5.10.19-100.fc32.x86_64 kernels.
>>
>> I attached patch with change proposal, I am not too sure about that. I
>> think frec->sentto is not enough, because it can forward query to
>> multiple servers in daemon->servers list. It seems like luck coincidence
>> that bound sockets (those with sentto->sfd != NULL) are at the end of
>> servers list. Meaning test in frec_lookup it can test frec->sentto->sfd.
>> If the last server were not the one with bound socket, this test would
>> never lead to sfd. Any reply to it would be ignored in that case. Now
>> all but the last one are ignored.
>>
>> I changed it to accept reply on any bound sockets if bound socket were
>> used to forward requests. It relaxes the test and might accept also from
>> unrelated sockets. But I have not found good and simple way to check
>> only servers used when sending. It fixes the problem on RHEL7. It might
>> lower security in some cases, but works fine on my case with Lenovo
>> laptop, Network Manager and dnsmasq forwarders configured over d-bus.
>>
>> Review, opinions or alternative ways to fix it welcome.
>>
>> Cheers,
>> Petr
>>
>> 1. https://bugzilla.redhat.com/show_bug.cgi?id=1923913
> 
> 
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: check_reply_fd.patch
Type: text/x-patch
Size: 1282 bytes
Desc: not available
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20210312/2a571df1/attachment-0001.bin>


More information about the Dnsmasq-discuss mailing list