bugtraq - Re: [VulnWatch] The Java applet sandbox and stateful firewalls

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <87slxtetuz.fsf@deneb.enyo.de>
Date: Mon, 01 Aug 2005 14:15:16 +0200
From: Florian Weimer <fw@...eb.enyo.de>
To: Dinis Cruz <dinis@...lus.net>
Cc: full-disclosure@...ts.grok.org.uk, bugtraq@...urityfocus.com,
	vulndiscuss@...nwatch.org, owasp-dotnet@...ts.sourceforge.net
Subject: Re: [VulnWatch] The Java applet sandbox and
	stateful firewalls

* Dinis Cruz:

> Is the Java Sandbox able to create outgoing connections on ports like 445?
>
> Also, even if it is possible, if a service like MS-SQL is already binded 
> to 1433, then wouldn't an error be thrown saying something like 'Port 
> already in use'.

This doesn't matter because in the PORT command sent to the FTP-like
server, the applet can reference a port which is not controlled by the
applet.  No checks take place, and it's perfectly possible to specify
an already bound port.  The firewall has no way to know that the port
actually belongs to some other process on the host (not the applet/FTP
client), and the sendbox does not examine the contents of TCP data
transfers at all.

Some NAT devices restrict access to 445/TCP, 139/TCP and a few more
ports, but by its nature, this list is incomplete and does not cover
all problematic TCP ports.
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/