> Mark Senior wrote:
> >
> > But, they've missed the big possibility for improvement here - they
> > have an application-aware firewall - why on earth would they not apply
> > it to outbound connections? No interesting malware requires inbound
> > connections anymore; it's already written to get past home routers
> > that allow all outbound and deny all inbound connections. Ah well.
> >
>
> That's an interesting point, but it's got its own set of problems. How
> would you know what all the different applications need to communicate
> with? You should be aware that mail reader has to have access to POP
> (and|or) IMAP and SMTP, maybe even newsgroups, and you have to know
> that for every single application out there, if you do not want to
> bother user with questions.
>

Indeed - Apple applications could come with predefined filters, just as a
few of them already come with prebuilt sandbox profiles - as you say, we
know that Mail.app will need to make outbound connections to POP3[S],
IMAP4[S], SMTP[S], NNTP (is there an NNTPS protocol?), and that should be
about it.

A downloaded program advertised as a single-player pinball game, however,
shouldn't need outbound connections, at all. If it really does, then the
developer had better actually write a line or two of documentation... And
if a program the user didn't even realize he was running, starts to asking
for permission to connect to an IRC server in China, you've caught the
malware.

Now, I was thinking a bit more about this, and Apple would probably have to
develop a serious capabilities framework for this to not be trivially
bypassable (maybe the new sandbox framework would actually be capable of
it). Otherwise, an application that is not trusted to make outgoing
connections, could simply shell out to one that is - for example, a piece of
malware could easily fork and exec the (Apple-provided, signed-binary)
netcat, and just pass traffic through pipes or Unix domain sockets.

The only way to make this really work, I think, would be to have the ability
to make network connections tied to the process object in the kernel, which
would have to be inherited all the way back from PID 1. Once a process
without the right to make network connections is executed, it loses that
ability, and cannot pass it on to any processes it spawns, regardless of
whether the executable in question has the ability to inherit such
permissions.

This still raises the challenge of processes inserting threads into other,
networking-allowed, processes. Some Windows malware gets around host based
application-aware firewalls in just this way, by inserting a DLL and a
thread into a process that is likely to have network permission, like
Internet Explorer. Either antivirus software, or the firewall itself, then
has to be on the lookout for that sort of malware-like behaviour. This
would require another element of the capabilities framework - the ability to
invoke create-thread type system calls on other processes, must never flow
from a networking-denied process, to a networking-allowed process.

And I'm sure I've missed about half a dozen other ways to bypass networking
restrictions that a determined malware writer could take. Even so - even
without watching for evasion techniques, the XP application firewall can
catch most current malware.

Fun stuff, isn't it? Cheers,
Mark
<br><br>
<div class="gmail_quote">On Nov 16, 2007 4:03 AM, Radoslav Dejanoviæ wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div class="Ih2E3d">Mark Senior wrote:<br>><br>> But, they've missed the big possibility for improvement here - they<br>> have an application-aware firewall - why on earth would they not apply<br>> it to outbound connections? No interesting malware requires inbound
<br>> connections anymore; it's already written to get past home routers<br>> that allow all outbound and deny all inbound connections. Ah well.<br>><br><br></div>That's an interesting point, but it's got its own set of problems. How
<br>would you know what all the different applications need to communicate<br>with? You should be aware that mail reader has to have access to POP<br>(and|or) IMAP and SMTP, maybe even newsgroups, and you have to know<br>
that for every single application out there, if you do not want to<br>bother user with questions.<br></blockquote></div>
<div> </div>
<div>Indeed - Apple applications could come with predefined filters, just as a few of them already come with prebuilt sandbox profiles - as you say, we know that Mail.app will need to make outbound connections to POP3[S], IMAP4[S], SMTP[S], NNTP (is there an NNTPS protocol?), and that should be about it.
</div>
<div> </div>
<div>A downloaded program advertised as a single-player pinball game, however, shouldn't need outbound connections, at all. If it really does, then the developer had better actually write a line or two of documentation... And if a program the user didn't even realize he was running, starts to asking for permission to connect to an IRC server in China, you've caught the malware.
</div>
<div> </div>
<div>Now, I was thinking a bit more about this, and Apple would probably have to develop a serious capabilities framework for this to not be trivially bypassable (maybe the new sandbox framework would actually be capable of it). Otherwise, an application that is not trusted to make outgoing connections, could simply shell out to one that is - for example, a piece of malware could easily fork and exec the (Apple-provided, signed-binary) netcat, and just pass traffic through pipes or Unix domain sockets.
</div>
<div> </div>
<div>The only way to make this really work, I think, would be to have the ability to make network connections tied to the process object in the kernel, which would have to be inherited all the way back from PID 1. Once a process without the right to make network connections is executed, it loses that ability, and cannot pass it on to any processes it spawns, regardless of whether the executable in question has the ability to inherit such permissions.
</div>
<div> </div>
<div>This still raises the challenge of processes inserting threads into other, networking-allowed, processes. Some Windows malware gets around host based application-aware firewalls in just this way, by inserting a DLL and a thread into a process that is likely to have network permission, like Internet Explorer. Either antivirus software, or the firewall itself, then has to be on the lookout for that sort of malware-like behaviour. This would require another element of the capabilities framework - the ability to invoke create-thread type system calls on other processes, must never flow from a networking-denied process, to a networking-allowed process.
</div>
<div> </div>
<div>And I'm sure I've missed about half a dozen other ways to bypass networking restrictions that a determined malware writer could take. Even so - even without watching for evasion techniques, the XP application firewall can catch most current malware.
</div>
<div> </div>
<div>Fun stuff, isn't it? Cheers,</div>
<div>Mark</div>