>> 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 ca
At 1:57 PM +0100 4/6/06, Dinis Cruz wrote:
>> At least one aspect of that is a design defect in TCP/IP, allowing
>> unprivileged users to create a port to receive inbound connections.
> If an application is a File Compression utility, then there is no reason
>why it should have access to the TCP
At 1:51 PM +0100 4/6/06, Dinis Cruz wrote:
> ljknews wrote:
>
> 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
der Mouse wrote:
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.
I agree
There is nothing at all in TCP or IP that
Comment inline,
ljknews wrote:
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
On 3/28/06, Michael S Hines <[EMAIL PROTECTED]> wrote:
> Isn't it possible to break out of the sandbox even with managed code? (That
> is, can't
> managed code call out to unmanaged code, i.e. Java call to C++)? I was
> thinking this was
> documented for Java - perhaps for various flavors of .Ne
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 ma
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
D]
Subject: [SC-L] 4 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
> 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
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 a
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 it
being released th
12 matches
Mail list logo
