Re: SA-14:19 (Denial of Service in TCP packet processing) and jails issue ?

2015-05-04 Thread Mike Tancsa

On 4/29/2015 6:07 PM, Mike Tancsa wrote:


The IP being scanned is in a jail.  If I run the scan to an IP not
associated with the jail, the scan does not complain. Its only on the
jailed IP that the scan flags as problematic for this vulnerability.

If this is a false positive, how can I be sure thats the case ? I have
pcaps of the scan both against the jailed IP (with the scan saying its
vulnerable) and against an IP not associated with the jail, saying its
not an issue.




Anyone have any have any ideas what can be done to mitigate this risk if 
its real, or if its a false positive ?


 To further clarify/describe my test environment, this is a RELENG_9 
box I am testing against. I have a number of IPs aliased to lo0 
associated with jails.  If I run the Qualsys scan against an IP on this 
box that is not associated with a jail, it passes the test for SA-14:19. 
 If I run the test against an IP associated with the jail, it fails the 
test.


e.g. IP 192.168.1.1 is aliased to lo0 and associated with jail1.sentex.ca.

If I run the free qualsys scan against jail1.sentex.ca, the test fails. 
 If I stop the jail, and run the qualsys scan against the same IP, 
which is now just an aliased IP on the host machine, it passes the test. 
 I have the pcaps, but I am not sure exactly what I am looking for in 
the data. The test just says it confirmed the vulnerability with the 
following 2 tests,


Tested on port 22 with an injected SYN/RST offset by 16 bytes.
Tested on port 25 with an injected SYN/RST offset by 16 bytes.

What is it about the jail that might be causing either this issue to 
resurface, or give a false positive that its an issue ?



---Mike



--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"


Re: SA-14:19 (Denial of Service in TCP packet processing) and jails issue ?

2015-05-04 Thread Julian Elischer

On 5/5/15 5:28 AM, Mike Tancsa wrote:

On 4/29/2015 6:07 PM, Mike Tancsa wrote:


The IP being scanned is in a jail.  If I run the scan to an IP not
associated with the jail, the scan does not complain. Its only on the
jailed IP that the scan flags as problematic for this vulnerability.

If this is a false positive, how can I be sure thats the case ? I have
pcaps of the scan both against the jailed IP (with the scan saying its
vulnerable) and against an IP not associated with the jail, saying its
not an issue.




Anyone have any have any ideas what can be done to mitigate this 
risk if its real, or if its a false positive ?

Firstly I assume you are not talking about a vimage jail?

It seems unlikely that jailing affects that processing. Does the test 
actually try cause the problem to occur? a tcpdump would be really nice.




 To further clarify/describe my test environment, this is a RELENG_9 
box I am testing against. I have a number of IPs aliased to lo0 
associated with jails.  If I run the Qualsys scan against an IP on 
this box that is not associated with a jail, it passes the test for 
SA-14:19.  If I run the test against an IP associated with the jail, 
it fails the test.


e.g. IP 192.168.1.1 is aliased to lo0 and associated with 
jail1.sentex.ca.


If I run the free qualsys scan against jail1.sentex.ca, the test 
fails.  If I stop the jail, and run the qualsys scan against the 
same IP, which is now just an aliased IP on the host machine, it 
passes the test.  I have the pcaps, but I am not sure exactly what I 
am looking for in the data. The test just says it confirmed the 
vulnerability with the following 2 tests,


Tested on port 22 with an injected SYN/RST offset by 16 bytes.
Tested on port 25 with an injected SYN/RST offset by 16 bytes.

What is it about the jail that might be causing either this issue to 
resurface, or give a false positive that its an issue ?



---Mike





___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"