<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2015-10-01 13:21 GMT+02:00 Kevin Darbyshire-Bryant <span dir="ltr"><<a href="mailto:kevin@darbyshire-bryant.me.uk" target="_blank">kevin@darbyshire-bryant.me.uk</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=""><br>
<br>
On 01/10/15 11:37, Etienne Champetier wrote:<br>
> Hi,<br>
><br>
> 2015-10-01 12:19 GMT+02:00 Kevin Darbyshire-Bryant<br>
</span>> <<a href="mailto:kevin@darbyshire-bryant.me.uk">kevin@darbyshire-bryant.me.uk</a> <mailto:<a href="mailto:kevin@darbyshire-bryant.me.uk">kevin@darbyshire-bryant.me.uk</a>>>:<br>
<span class="">><br>
>     This patch stops SIGHUP from enabling dnssec timechecks if disabled by<br>
>     use of --dnssec-no-timecheck option.  --dnssec-timestamp continues to<br>
>     work correctly.<br>
><br>
><br>
> I haven't really followed the previous discusion,<br>
> but maybe you can just use another signal?<br>
</span>The user defined signals USR1 & USR2 are already occupied by dnsmasq<br>
with debug/info dump type functions.  Maybe one of the SIGTT* signals<br>
could be repurposed but I don't know how valid a solution that is.<br>
<br>
However even if that were done it still doesn't stop a malicious<br>
user/process from sending that new signal and potentially disabling dns<br>
resolution (assuming dnssec is being used & the system time is incorrect)<br></blockquote><div><br></div><div>you can only signal yourself<br><a href="http://stackoverflow.com/a/13335054/3768051">http://stackoverflow.com/a/13335054/3768051</a><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Ideally some evaluation of threat presented by 'sysfixtime', 'dnssec<br>
timestamp files', 'dnssec no timecheck' and the multi-function<br>
'overloading' of SIGHUP into dnsmasq in the context of dnssec &<br>
correct/incorrect system time should take place and an appropriate,<br>
considered response and solution proposed/implemented.  That person<br>
isn't me ;-)<br>
<br>
I personally think that sysfixtime is a necessary evil, but at the very<br>
least at the present moment until a more correct solution is<br>
implemented, it should not be using dnsmasq's timestamp file as a source<br>
time reference on boot.<br>
<span class=""><br>
<br>
><br>
><br>
><br>
>     Enabling dnssec timechecks now requires restarting dnsmasq without<br>
>     the --dnssec-no-timecheck configuration option and closes a<br>
>     potential denial of service exploit by sending SIGHUP when system<br>
>     time does not correspond with Internet time.<br>
><br>
><br>
><br>
><br>
>     This change may be useful for future ntpd/dnsmasq hotplug integration.<br>
><br>
><br>
>     Signed-off-by: Kevin Darbyshire-Bryant<br>
</span>>     <<a href="mailto:kevin@darbyshire-bryant.me.uk">kevin@darbyshire-bryant.me.uk</a> <mailto:<a href="mailto:kevin@darbyshire-bryant.me.uk">kevin@darbyshire-bryant.me.uk</a>>><br>
<div class=""><div class="h5">>     ---<br>
>      .../dnsmasq/patches/220-dnssec-disable-timecheck-hup.patch  | 13<br>
>     +++++++++++++<br>
>      1 file changed, 13 insertions(+)<br>
>      create mode 100644<br>
>     package/network/services/dnsmasq/patches/220-dnssec-disable-timecheck-hup.patch<br>
><br>
><br>
<br>
<br>
</div></div></blockquote></div><br></div></div>