[Bug 238796] ipfilter: fix unremovable rules and rules checksum for comparison
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238796 --- Comment #15 from Cy Schubert --- That's perfect, thank you. I'll do some testing here. I suspect the cause is similar to a panic I am working on. Use your patch or the improved patch I posted here while I dig into the root cause. -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 238796] ipfilter: fix unremovable rules and rules checksum for comparison
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238796 --- Comment #14 from WHR --- Good news. I has reproduced this bug in a FreeBSD 13.0-CURRENT r349753 testing VM. The steps are: kldload ipl.ko ifconfig tun0 plumb ifconfig tun1 plumb echo "pass in quick reply-to tun0:10.1.1.1 on tun0 proto tcp from any to 10.1.1.11 port = 22 flags S/FSRPAU keep state" | ipf -f - echo "pass in quick reply-to tun1:10.1.2.1 on tun1 proto tcp from any to 10.1.2.11 port = 22 flags S/FSRPAU keep state" | ipf -f - echo "pass in quick reply-to tun0:10.1.1.1 on tun0 proto tcp from any to 10.1.1.11 port = 22 flags S/FSRPAU keep state" | ipf -f - ipfstat -Rion echo "pass in quick route-to tun1:10.1.2.1 on em0 proto tcp from 10.0.3.63 to any" | ipf -f - echo "pass in quick route-to tun0:10.1.1.1 on em0 proto tcp from 10.0.3.64 to any port = 23" | ipf -f - echo "pass in quick reply-to tun0:10.1.1.1 on tun0 proto tcp from any to 10.1.1.11 port = 22 flags S/FSRPAU keep state" | ipf -f - ipfstat -Ri ipfstat -Ri | ipf -f - Please tell if you want the VM configuration or the disk image. -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: ipfilter not creating entries in the state table
Any chance someone with a better understanding of how stateful firewall rules work able to take a look at this with me? I'm trying to make my firewall ruleset rock solid in the long run and this is one of the occasions where Ihaven't been able to do so yet. Any comment appreciated! Steffen On Wed, Jul 03, 2019 at 05:42:29PM +0100, Steffen Rick wrote: > Hi, > > hoping you guys can help me with this. I'm somehow unable to create an > ipfilter configuration that will use stateful filtering on IPv6. What > I have is a very simple ipf.rules file: > > ipf.rules: > pass in quick on lo0 all > pass out quick on lo0 all > > pass out quick on re0 all keep state > > pass in quick on re0 proto tcp from any to any port = 22 > > block in log quick on re0 all > > default kernel wise is to accept traffic > (I do this to not log myself out when working remotely) > > When I lookup www.google.com over IPv4 I get an entry in the state table > > dig -A www.google.com @8.8.8.8 > ipfstat -t > Src: 0.0.0.0, Dest: 0.0.0.0, Proto: any, Sorted by: # bytes > > Source IP Destination IP ST PR #pkts#bytes > ttl > 188.40.60.69,22 80.79.143.188,47160 4/4 tcp 75 14048 > 119:59:59 > 188.40.60.96,511268.8.8.8,530/0 udp 183 > 0:03 > > When I try to lookup the A record on the IPv6 server I get no state table > entry > > dig -A www.google.com @2001:4860:4860:: > no state table entry and no response from the server > > tcpdump -nnn host 2001:4860:4860:: > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on re0, link-type EN10MB (Ethernet), capture size 262144 bytes > 16:48:48.588867 IP6 2a01:4f8:221:181::2.62706 > 2001:4860:4860::.53: > 15010+ [1au] A? www.google.com. (55) > 16:48:48.602580 IP6 2001:4860:4860::.53 > 2a01:4f8:221:181::2.62706: > 15010 1/0/1 A 216.58.206.4 (59) > 16:48:53.663637 IP6 2a01:4f8:221:181::2.62706 > 2001:4860:4860::.53: > 15010+ [1au] A? www.google.com. (55) > 16:48:53.668845 IP6 2001:4860:4860::.53 > 2a01:4f8:221:181::2.62706: > 15010 1/0/1 A 216.58.206.4 (59) > 16:48:58.744154 IP6 2a01:4f8:221:181::2.62706 > 2001:4860:4860::.53: > 15010+ [1au] A? www.google.com. (55) > 16:48:58.764794 IP6 2001:4860:4860::.53 > 2a01:4f8:221:181::2.62706: > 15010 1/0/1 A 216.58.206.4 (59) > ^C > > The request seems to have gone through just fine but my dig client times out. > > I change the ruleset to include > > pass in quick on re0 inet6 proto tcp from any port = 53 > pass in quick on re0 inet6 proto udp from any port = 53 > > and then I'm obviously able to get a response from the server. > > tcpdump -nnn host 2001:4860:4860:: > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on re0, link-type EN10MB (Ethernet), capture size 262144 bytes > 16:47:36.738177 IP6 2a01:4f8:221:181::2.40852 > 2001:4860:4860::.53: > 54683+ [1au] A? www.google.com. (55) > 16:47:36.751447 IP6 2001:4860:4860::.53 > 2a01:4f8:221:181::2.40852: > 54683 1/0/1 A 172.217.18.164 (59) > ^C > > That obiously ignores the statefulness of the firewall. Is this a > known issue? Has anyone ipfilter working with stateful rules correctly > being created when making outbound requests? > > Any help appreciated! > > Thanks, > Steffen > ___ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 238796] ipfilter: fix unremovable rules and rules checksum for comparison
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238796 --- Comment #13 from Cy Schubert --- Unfortunately I cannot accept patches until I can reproduce the problem here. I have tested the rule in a VM with INVARIANTS and on my production firewall without INVARIANTS. I am unable to verify that this is a bug. Or, what makes your one machine different from all the others needs to be discovered. Then I can reproduce it here. If you can provide me with something I can reproduce the scenario here I will be open to committing an updated version of your patch. Otherwise I am not able to justify an unverified patch. -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
panic on epair destroy in current as of r349853, jail related
Hi,
I updated from r347365 to r349853. Now I get a panic on epair destroy
(one end needs to be in a jail, and inside the jail an IP address
needs to be assigned to the epair. If no ifconfig is used inside the
jail, there is no panic.
Another user reported something similar (but for him it was enough to
list the interfaces inside the jail with ifconfig) in PR 234985:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234985
Backtrace (here I also renamed the interface before attaching it to
the jail, as I detected the issue with interfaces which are renamed):
Fatal trap 9: general protection fault while in kernel mode
cpuid = 13; apic id = 33
instruction pointer = 0x20:0x805f2045
stack pointer = 0x28:0xfe0159822880
frame pointer = 0x28:0xfe0159822880
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 43334 (ifconfig)
trap number = 9
panic: general protection fault
cpuid = 13
time = 1562695289
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0159822590
vpanic() at vpanic+0x19d/frame 0xfe01598225e0
panic() at panic+0x43/frame 0xfe0159822640
trap_fatal() at trap_fatal+0x39c/frame 0xfe01598226a0
trap() at trap+0x6c/frame 0xfe01598227b0
calltrap() at calltrap+0x8/frame 0xfe01598227b0
--- trap 0x9, rip = 0x805f2045, rsp = 0xfe0159822880, rbp
= 0xfe0159822880 ---
strncmp() at strncmp+0x15/frame 0xfe0159822880
ifunit_ref() at ifunit_ref+0x51/frame 0xfe01598228c0
ifioctl() at ifioctl+0x508/frame 0xfe0159822990
kern_ioctl() at kern_ioctl+0x26d/frame 0xfe0159822a00
sys_ioctl() at sys_ioctl+0x15d/frame 0xfe0159822ad0
amd64_syscall() at amd64_syscall+0x23a/frame 0xfe0159822bf0
fast_syscall_common() at fast_syscall_common+0x101/frame 0xfe0159822bf0
--- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8004690da, rsp =
0x7fffe448, rbp = 0x7fffe4b0 ---
Uptime: 3h34m59s
Dumping 5294 out of 61352 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%
__curthread () at /space/system/usr_src/sys/amd64/include/pcpu.h:246
246 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n"
(OFFSETOF_CURTHREAD));
(kgdb) #0 __curthread () at
/space/system/usr_src/sys/amd64/include/pcpu.h:246
#1 doadump (textdump=1) at /space/system/usr_src/sys/kern/kern_shutdown.c:392
#2 0x8050cf70 in kern_reboot (howto=260)
at /space/system/usr_src/sys/kern/kern_shutdown.c:479
#3 0x8050d3e9 in vpanic (fmt=, ap=)
at /space/system/usr_src/sys/kern/kern_shutdown.c:905
#4 0x8050d123 in panic (fmt=)
at /space/system/usr_src/sys/kern/kern_shutdown.c:832
#5 0x807e758c in trap_fatal (frame=0xfe01598227c0, eva=0)
at /space/system/usr_src/sys/amd64/amd64/trap.c:943
#6 0x807e698c in trap (frame=0xfe01598227c0)
at /space/system/usr_src/sys/amd64/amd64/trap.c:221
#7
#8 0x805f2045 in strncmp (s1=, s2=,
n=) at /space/system/usr_src/sys/libkern/strncmp.c:44
#9 0x80605d31 in ifunit_ref (name=0xfe0159822a20 "panic_test1b")
at /space/system/usr_src/sys/net/if.c:2434
#10 0x80607ef8 in ifioctl (so=0xf809a1afd368, cmd=3223349536,
data=0xfe0159822a20 "panic_test1b", td=0xf8014c83e5a0)
at /space/system/usr_src/sys/net/if.c:3093
#11 0x8057658d in fo_ioctl (fp=, com=3223349536,
data=0xf800020e2180, active_cred=0x0, td=0xf8014c83e5a0)
at /space/system/usr_src/sys/sys/file.h:333
#12 kern_ioctl (td=0xf8014c83e5a0, fd=3, com=3223349536,
data=0xf800020e2180 "")
at /space/system/usr_src/sys/kern/sys_generic.c:800
#13 0x805762ad in sys_ioctl (td=0xf8014c83e5a0,
uap=0xf8014c83e968) at
/space/system/usr_src/sys/kern/sys_generic.c:712
#14 0x807e801a in syscallenter (td=0xf8014c83e5a0)
at /space/system/usr_src/sys/amd64/amd64/../../kern/subr_syscall.c:135
#15 amd64_syscall (td=0xf8014c83e5a0, traced=0)
at /space/system/usr_src/sys/amd64/amd64/trap.c:1181
#16
#17 0x0008004690da in ?? ()
Backtrace stopped: Cannot access memory at address 0x7fffe448
Bye,
Alexander.
--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF
pgpyS8IAW0K1s.pgp
Description: Digitale PGP-Signatur
Re: Issues with TCP Timestamps allocation
> On 9. Jul 2019, at 14:58, Paul wrote:
>
> Hi Michael,
>
> 9 July 2019, 15:34:29, by "Michael Tuexen" :
>
>>
>>
>>> On 8. Jul 2019, at 17:22, Paul wrote:
>>>
>>>
>>>
>>> 8 July 2019, 17:12:21, by "Michael Tuexen" :
>>>
> On 8. Jul 2019, at 15:24, Paul wrote:
>
> Hi Michael,
>
> 8 July 2019, 15:53:15, by "Michael Tuexen" :
>
>>> On 8. Jul 2019, at 12:37, Paul wrote:
>>>
>>> Hi team,
>>>
>>> Recently we had an upgrade to 12 Stable. Immediately after, we have
>>> started
>>> seeing some strange connection establishment timeouts to some fixed
>>> number
>>> of external (world) hosts. The issue was persistent and easy to
>>> reproduce.
>>> Thanks to a patience and dedication of our system engineer we have
>>> tracked
>>> this issue down to a specific commit:
>>>
>>> https://svnweb.freebsd.org/base?view=revision&revision=338053
>>>
>>> This patch was also back-ported into 11 Stable:
>>>
>>> https://svnweb.freebsd.org/base?view=revision&revision=348435
>>>
>>> Among other things this patch changes the timestamp allocation strategy,
>>> by introducing a deterministic randomness via a hash function that takes
>>> into account a random key as well as source address, source port, dest
>>> address and dest port. As the result, timestamp offsets of different
>>> tuples (SA,SP,DA,DP) will be wildly different and will jump from small
>>> to large numbers and back, as long as something in the tuple changes.
>> Hi Paul,
>>
>> this is correct.
>>
>> Please note that the same happens with the old method, if two hosts with
>> different uptimes are bind a consumer grade NAT.
>
> If NAT does not replace timestamps then yes, it should be the case.
>
>>>
>>> After performing various tests of hosts that produce the above
>>> mentioned
>>> issue we came to conclusion that there are some interesting
>>> implementations
>>> that drop SYN packets with timestamps smaller than the largest
>>> timestamp
>>> value from streams of all recent or current connections from a specific
>>> address. This looks as some kind of SYN flood protection.
>> This also breaks multiple hosts with different uptimes behind a consumer
>> level NAT talking to such a server.
>>>
>>> To ensure that each external host is not going to see a wild jumps of
>>> timestamp values I propose a patch that removes ports from the equation
>>> all together, when calculating the timestamp offset:
>>>
>>> Index: sys/netinet/tcp_subr.c
>>> ===
>>> --- sys/netinet/tcp_subr.c (revision 348435)
>>> +++ sys/netinet/tcp_subr.c (working copy)
>>> @@ -2224,7 +2224,22 @@
>>> uint32_t
>>> tcp_new_ts_offset(struct in_conninfo *inc)
>>> {
>>> - return (tcp_keyed_hash(inc, V_ts_offset_secret));
>>> +/*
>>> + * Some implementations show a strange behaviour when a wildly
>>> random
>>> + * timestamps allocated for different streams. It seems that
>>> only the
>>> + * SYN packets are affected. Observed implementations drop SYN
>>> packets
>>> + * with timestamps smaller than the largest timestamp value of
>>> all
>>> + * recent or current connections from specific a address. To
>>> mitigate
>>> + * this we are going to ensure that each host will always
>>> observe
>>> + * timestamps as increasing no matter the stream: by dropping
>>> ports
>>> + * from the equation.
>>> + */
>>> +struct in_conninfo inc_copy = *inc;
>>> +
>>> +inc_copy.inc_fport = 0;
>>> +inc_copy.inc_lport = 0;
>>> +
>>> + return (tcp_keyed_hash(&inc_copy, V_ts_offset_secret));
>>> }
>>>
>>> /*
>>>
>>> In any case, the solution of the uptime leak, implemented in rev338053
>>> is
>>> not going to suffer, because a supposed attacker is currently able to
>>> use
>>> any fixed values of SP and DP, albeit not 0, anyway, to remove them out
>>> of the equation.
>> Can you describe how a peer can compute the uptime from two observed
>> timestamps?
>> I don't see how you can do that...
>
> Supposed attacker could run a script that continuously monitors
> timestamps,
> for example via a periodic TCP connection from a fixed local port (eg
> 12345)
> and a fixed local address to the fixed victim's address and port (eg 80).
> Whenever large discrepancy is observed, attacker can assume that reboot
> has
> happened (due to V_ts_offset_secret re-generation), hence the received
> timestamp is considered an approximate point of reboot from w
[Bug 238796] ipfilter: fix unremovable rules and rules checksum for comparison
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238796 --- Comment #12 from WHR --- (In reply to Cy Schubert from comment #11) Although this bug is always reproduce on that particular machine, with both 12.0-STABLE and 13.0-CURRENT kernels, I failed to reproduce it on a testing VM. I plan to install another test VM with FreeBSD 13.0-CURRENT, tomorrow. -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re[2]: Issues with TCP Timestamps allocation
Hi Michael,
9 July 2019, 15:34:29, by "Michael Tuexen" :
>
>
> > On 8. Jul 2019, at 17:22, Paul wrote:
> >
> >
> >
> > 8 July 2019, 17:12:21, by "Michael Tuexen" :
> >
> >>> On 8. Jul 2019, at 15:24, Paul wrote:
> >>>
> >>> Hi Michael,
> >>>
> >>> 8 July 2019, 15:53:15, by "Michael Tuexen" :
> >>>
> > On 8. Jul 2019, at 12:37, Paul wrote:
> >
> > Hi team,
> >
> > Recently we had an upgrade to 12 Stable. Immediately after, we have
> > started
> > seeing some strange connection establishment timeouts to some fixed
> > number
> > of external (world) hosts. The issue was persistent and easy to
> > reproduce.
> > Thanks to a patience and dedication of our system engineer we have
> > tracked
> > this issue down to a specific commit:
> >
> > https://svnweb.freebsd.org/base?view=revision&revision=338053
> >
> > This patch was also back-ported into 11 Stable:
> >
> > https://svnweb.freebsd.org/base?view=revision&revision=348435
> >
> > Among other things this patch changes the timestamp allocation strategy,
> > by introducing a deterministic randomness via a hash function that takes
> > into account a random key as well as source address, source port, dest
> > address and dest port. As the result, timestamp offsets of different
> > tuples (SA,SP,DA,DP) will be wildly different and will jump from small
> > to large numbers and back, as long as something in the tuple changes.
> Hi Paul,
>
> this is correct.
>
> Please note that the same happens with the old method, if two hosts with
> different uptimes are bind a consumer grade NAT.
> >>>
> >>> If NAT does not replace timestamps then yes, it should be the case.
> >>>
> >
> > After performing various tests of hosts that produce the above
> > mentioned
> > issue we came to conclusion that there are some interesting
> > implementations
> > that drop SYN packets with timestamps smaller than the largest
> > timestamp
> > value from streams of all recent or current connections from a specific
> > address. This looks as some kind of SYN flood protection.
> This also breaks multiple hosts with different uptimes behind a consumer
> level NAT talking to such a server.
> >
> > To ensure that each external host is not going to see a wild jumps of
> > timestamp values I propose a patch that removes ports from the equation
> > all together, when calculating the timestamp offset:
> >
> > Index: sys/netinet/tcp_subr.c
> > ===
> > --- sys/netinet/tcp_subr.c (revision 348435)
> > +++ sys/netinet/tcp_subr.c (working copy)
> > @@ -2224,7 +2224,22 @@
> > uint32_t
> > tcp_new_ts_offset(struct in_conninfo *inc)
> > {
> > - return (tcp_keyed_hash(inc, V_ts_offset_secret));
> > +/*
> > + * Some implementations show a strange behaviour when a wildly
> > random
> > + * timestamps allocated for different streams. It seems that
> > only the
> > + * SYN packets are affected. Observed implementations drop SYN
> > packets
> > + * with timestamps smaller than the largest timestamp value of
> > all
> > + * recent or current connections from specific a address. To
> > mitigate
> > + * this we are going to ensure that each host will always
> > observe
> > + * timestamps as increasing no matter the stream: by dropping
> > ports
> > + * from the equation.
> > + */
> > +struct in_conninfo inc_copy = *inc;
> > +
> > +inc_copy.inc_fport = 0;
> > +inc_copy.inc_lport = 0;
> > +
> > + return (tcp_keyed_hash(&inc_copy, V_ts_offset_secret));
> > }
> >
> > /*
> >
> > In any case, the solution of the uptime leak, implemented in rev338053
> > is
> > not going to suffer, because a supposed attacker is currently able to
> > use
> > any fixed values of SP and DP, albeit not 0, anyway, to remove them out
> > of the equation.
> Can you describe how a peer can compute the uptime from two observed
> timestamps?
> I don't see how you can do that...
> >>>
> >>> Supposed attacker could run a script that continuously monitors
> >>> timestamps,
> >>> for example via a periodic TCP connection from a fixed local port (eg
> >>> 12345)
> >>> and a fixed local address to the fixed victim's address and port (eg 80).
> >>> Whenever large discrepancy is observed, attacker can assume that reboot
> >>> has
> >>> happened (due to V_ts_offset_secret re-generation), hence the received
> >>> timestamp is considered an approximate point of reboot from which the
> >>> uptime
> >>> can be calculated, until the
Re: Issues with TCP Timestamps allocation
> On 8. Jul 2019, at 17:22, Paul wrote:
>
>
>
> 8 July 2019, 17:12:21, by "Michael Tuexen" :
>
>>> On 8. Jul 2019, at 15:24, Paul wrote:
>>>
>>> Hi Michael,
>>>
>>> 8 July 2019, 15:53:15, by "Michael Tuexen" :
>>>
> On 8. Jul 2019, at 12:37, Paul wrote:
>
> Hi team,
>
> Recently we had an upgrade to 12 Stable. Immediately after, we have
> started
> seeing some strange connection establishment timeouts to some fixed number
> of external (world) hosts. The issue was persistent and easy to reproduce.
> Thanks to a patience and dedication of our system engineer we have
> tracked
> this issue down to a specific commit:
>
> https://svnweb.freebsd.org/base?view=revision&revision=338053
>
> This patch was also back-ported into 11 Stable:
>
> https://svnweb.freebsd.org/base?view=revision&revision=348435
>
> Among other things this patch changes the timestamp allocation strategy,
> by introducing a deterministic randomness via a hash function that takes
> into account a random key as well as source address, source port, dest
> address and dest port. As the result, timestamp offsets of different
> tuples (SA,SP,DA,DP) will be wildly different and will jump from small
> to large numbers and back, as long as something in the tuple changes.
Hi Paul,
this is correct.
Please note that the same happens with the old method, if two hosts with
different uptimes are bind a consumer grade NAT.
>>>
>>> If NAT does not replace timestamps then yes, it should be the case.
>>>
>
> After performing various tests of hosts that produce the above mentioned
> issue we came to conclusion that there are some interesting
> implementations
> that drop SYN packets with timestamps smaller than the largest timestamp
> value from streams of all recent or current connections from a specific
> address. This looks as some kind of SYN flood protection.
This also breaks multiple hosts with different uptimes behind a consumer
level NAT talking to such a server.
>
> To ensure that each external host is not going to see a wild jumps of
> timestamp values I propose a patch that removes ports from the equation
> all together, when calculating the timestamp offset:
>
> Index: sys/netinet/tcp_subr.c
> ===
> --- sys/netinet/tcp_subr.c(revision 348435)
> +++ sys/netinet/tcp_subr.c(working copy)
> @@ -2224,7 +2224,22 @@
> uint32_t
> tcp_new_ts_offset(struct in_conninfo *inc)
> {
> - return (tcp_keyed_hash(inc, V_ts_offset_secret));
> +/*
> + * Some implementations show a strange behaviour when a wildly
> random
> + * timestamps allocated for different streams. It seems that
> only the
> + * SYN packets are affected. Observed implementations drop SYN
> packets
> + * with timestamps smaller than the largest timestamp value of
> all
> + * recent or current connections from specific a address. To
> mitigate
> + * this we are going to ensure that each host will always
> observe
> + * timestamps as increasing no matter the stream: by dropping
> ports
> + * from the equation.
> + */
> +struct in_conninfo inc_copy = *inc;
> +
> +inc_copy.inc_fport = 0;
> +inc_copy.inc_lport = 0;
> +
> + return (tcp_keyed_hash(&inc_copy, V_ts_offset_secret));
> }
>
> /*
>
> In any case, the solution of the uptime leak, implemented in rev338053 is
> not going to suffer, because a supposed attacker is currently able to use
> any fixed values of SP and DP, albeit not 0, anyway, to remove them out
> of the equation.
Can you describe how a peer can compute the uptime from two observed
timestamps?
I don't see how you can do that...
>>>
>>> Supposed attacker could run a script that continuously monitors timestamps,
>>> for example via a periodic TCP connection from a fixed local port (eg
>>> 12345)
>>> and a fixed local address to the fixed victim's address and port (eg 80).
>>> Whenever large discrepancy is observed, attacker can assume that reboot has
>>> happened (due to V_ts_offset_secret re-generation), hence the received
>>> timestamp is considered an approximate point of reboot from which the uptime
>>> can be calculated, until the next reboot and so on.
>> Ahh, I see. The patch we are talking about is not intended to protect against
>> continuous monitoring, which is something you can always do. You could even
>> watch for service availability and detect reboots. A change of the local key
>> would also look similar to a reboot without a temporary loss of connectivity.
>>
>> Thanks for the
[Bug 238796] ipfilter: fix unremovable rules and rules checksum for comparison
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238796 --- Comment #11 from Cy Schubert --- Unfortunately I cannot accept a patch for something I cannot reproduce. AFAIAC your patch does not fix any bug. Help me reproduce it here then. A patch for something I cannot verify or reproduce is not enough. If this is a bug, what do I do to expose it? I need your help then. Help me verify that this is indeed a bug. Help me out here. -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 238796] ipfilter: fix unremovable rules and rules checksum for comparison
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238796 WHR changed: What|Removed |Added Status|Closed |Open Resolution|Not A Bug |--- --- Comment #10 from WHR --- (In reply to Cy Schubert from comment #9) I never said I has used any custom patch when discovering this bug, the only patch 'attachment 205322' is used to FIX the bug. In fact the 2 kernel images and associated 'ipl.ko' KLD module are downloaded directly from FreeBSD download site, with version 12.0-STABLE r349024 and 13.0-CURRENT r349753. -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
