Hi Simon
On Monday 29 Sep 2014 20:17:56 Simon Kelley wrote:
There's no definition of what is allowed in those DHCP options, so it's
quite possible that a shell metacharacter would be encountered.
Sanitising the strings would therefore change what gets passed to the
script, ie it would be an
Hi Simon,
the related code is indeed really simple. I have no idea how that could happen
at all. However, I am no longer able to reproduce it :(
It might be some corner case or so, idk. I also added some debug logging and
watched it in gdb but no luck. I hope it's really gone now, whatever caused
2014-09-03 10:37 GMT+04:00 Vladislav Grishenko themi...@mail.ru:
Sorry, misread.
dnsmasq sends unsolicited periodic RA and sends solicited RA in reply to
incoming RS from client only.
dnsmasq may send several NS to client in reply to incoming DHCPv6 requests to
know its hw address (mac).
On Sep 30, 2014, at 1:05 AM, Roy Marples r...@marples.name wrote:
Of course, the shell isn't supposed to interpret metacharacters in the
value of shell variables unless explicitly told to: so sanitising
shouldn't be required (though I concede it would mitigate a lot of
common shell-script
The problem is that there seems to be no standard for what characters have
special meaning in environment variables (other than the usual none do
which bash is violating here). Without that, or at least a guarantee that
certain character AREN'T special, it's not possible to sanitize.
On Tue, Sep
SO_MARK has to be done before issuing the connect() call on the
TCP socket.
---
src/forward.c | 35 ++-
1 files changed, 18 insertions(+), 17 deletions(-)
diff --git a/src/forward.c b/src/forward.c
index 4895efe..c9dedc3 100644
--- a/src/forward.c
+++
On 2014-09-30 13:33, Nicholas Weaver wrote:
Although, to be honest, although the DHCP vector is trivial to exploit
[1], if the attacker can give you a bogus DHCP reply you've lost
already.
At this point, the attacker already has a full man-in-the-middle of
all network traffic, and can easily
On some setups, the resolv.conf file might be updated/changed
within the 1 second granularity that st_mtime provides, therefor
also keep track of the nanoseconds.
NOTE: not all filesystems have nanosecond timestamps, but in that
case, the nanosecond field will be set to 0 by the kernel.
---
First version of the patch generated a compiler warning due
to improper initialization of a variable.
Karl Vogel (1):
Use nanosecond granularity when checking for file changes.
src/dnsmasq.c | 20 +++-
src/dnsmasq.h |7 ++-
src/option.c |3 ++-
3 files changed,
