If an application is a File Compression utility, then there is no
reason why it should have access to the TCP stack.
The problem then, is how to prevent an unprivileged user from setting
up a File Compression utility to access TCP and establish a port to
which an incoming connection can be
If you are able to make direct calls to unmanaged code, then yes you can
jump out of the sandbox (assuming that you are in one in the first place)
The environment that I am talking about is one where you have managed
and verifiable code which is not allowed to perform dangerous actions
(such as
At least one aspect of that is a design defect in TCP/IP, allowing
unprivileged users to create a port to receive inbound connections.
I don't think it's fair to call that any kind of defect in TCP/IP.
There is nothing at all in TCP or IP that says anything whatsoever
about what privilege may
Questions: Latest IE vulnerability, Firefox vs IE security,
User vs
Admin risk profile, and browsers coded in 100% Managed Verifiable code
Another day, and another unmanaged-code remote command execution in IE.
What is relevant in the ISS alert (see end of this post) is that IE 7
beta 2 is also
Dinis Cruz said:
Another day, and another unmanaged-code remote command execution in IE.
What is relevant in the ISS alert (see end of this post) is that IE 7
beta 2 is also vulnerable, which leads me to this post's questions:
1) Will IE 7.0 be more secure than IE 6.0 (i.e. will after 2 years
At 11:39 AM + 3/25/06, Dinis Cruz wrote:
3) Since my assets as a user exist in user land, isn't the risk profile
of malicious unmanaged code (deployed via IE/Firefox) roughly the same
if I am running as a 'low privileged' user or as administrator? (at the
If the administrator's assets are
