pppd security

pppd security

[jfj]

Hi.

I don't know much about pppd so this may be completely
wrong.

Suppose this setup:

I have a custom kernel which "secures" sockets. That is,
any program that will try to use a socket without "unlocking"
it first, will get some ERROR. This way, only trusted
programs will be able to use sockets and connect to the
net.

So, sockets are secured at the TCP/IP layers.

My question now is, if it is possible to attack this by
sending data directly to the PPP layer. Can one open
/dev/ppp, construct a UDP packet, encapsulate this into
a PPP packet, write it to some /dev/ppp device and reach
some internet host?

Thanks,

jerald

Re: pppd security

[James Carlson]

jfj writes:
> My question now is, if it is possible to attack this by
> sending data directly to the PPP layer. Can one open
> /dev/ppp, construct a UDP packet, encapsulate this into
> a PPP packet, write it to some /dev/ppp device and reach
> some internet host?

No more or less so than it's possible to do the same via an Ethernet
adapter.

/dev/ppp provides a datalink layer interface to the system.  The
security on such interfaces (in general) ought to be the same.

(Note that you wouldn't want to "encapsulate" it as PPP.  That's what
the PPP driver itself does.  If you were to open /dev/ppp for such a
hack, you'd transmit raw IP packets, much in the same way you would if
you opened an Ethernet driver.)

-- 
James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>

Re: pppd security

[jfj]

James Carlson wrote:

> No more or less so than it's possible to do the same via an Ethernet
> adapter.


 > /dev/ppp provides a datalink layer interface to the system. The
 > security on such interfaces (in general) ought to be the same.

So it is possible to dump UDP packets to /dev/ppp (and /dev/eth (and PPP
packets to /dev/tty)). More or less...

If I understand correctly, the only program that is supposed to use
/dev/ppp is pppd, to establish the connection. After that the packets
go there through the internal TCP/IP stack. And noone else should
be messing with /dev/ppp normally.

If so, does it sound like a feasible idea to hack the kernel to forbid
opening the /dev/ppp device to other processes, once pppd is working?

Another idea is to rename /dev/ppp to /dev/secretppp and hack pppd
to use that instead?

Other ideas to lock access to /dev/ppp?

Thanks,

jerald

Re: pppd security

[James Carlson]

jfj writes:
> 
> James Carlson wrote:
> 
> > No more or less so than it's possible to do the same via an Ethernet
> > adapter.
> 
> 
>  > /dev/ppp provides a datalink layer interface to the system. The
>  > security on such interfaces (in general) ought to be the same.
> 
> So it is possible to dump UDP packets to /dev/ppp (and /dev/eth (and PPP
> packets to /dev/tty)). More or less...
> 
> If I understand correctly, the only program that is supposed to use
> /dev/ppp is pppd, to establish the connection.

Yes.

> After that the packets
> go there through the internal TCP/IP stack. And noone else should
> be messing with /dev/ppp normally.

That's right.

> If so, does it sound like a feasible idea to hack the kernel to forbid
> opening the /dev/ppp device to other processes, once pppd is working?

It sounds plausible, but since I don't understand the trust model
you're working with, I'm afraid I can't address the broader questions.

(In particular, pppd needs a substantial amount of privilege in order
to run the /etc/ppp/ip-{up,down} scripts properly.  Given that level
of privilege, and the trust that it necessarily implies, I think that
if you have problems in pppd, you're already sunk, no matter how you
try to limit the scope.)

> Another idea is to rename /dev/ppp to /dev/secretppp and hack pppd
> to use that instead?

I don't see any point to that at all.  That'd just be security-by-
obscurity.

> Other ideas to lock access to /dev/ppp?

I'd worry first about the trust model.  Trusted applications shouldn't
be jumping through hoops to get the job done, because if they're
compromised, then all bets are already off.

-- 
James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>

Re: pppd security

[jfj]

James Carlson wrote:

>>If so, does it sound like a feasible idea to hack the kernel to forbid
>>opening the /dev/ppp device to other processes, once pppd is working?
> 
> 
> It sounds plausible, but since I don't understand the trust model
> you're working with, I'm afraid I can't address the broader questions.
> 
> (In particular, pppd needs a substantial amount of privilege in order
> to run the /etc/ppp/ip-{up,down} scripts properly.  Given that level
> of privilege, and the trust that it necessarily implies, I think that
> if you have problems in pppd, you're already sunk, no matter how you
> try to limit the scope.)
> 

The trust model is this: We suppose that malware is running.
Suppose from a buffer overflow in libPNG which achieved
priviledge escallation to root. It is OK for malware to run but
it will not be able to connect to anyone. Thus the attacker
will be blind, he will never know that the malware is
working and it will operate in isolation. Therefore,
nobody will be able to *control* the host or *get* data from
it. Sure, the running malware may delete everything :)

So the host may be compromised but it will be more like the
good old viruses that were transmitted in the boot sector
and didn't have a link to their creator.

Anyway. Thanks for the tips.

jerald

Re: pppd security

[James Carlson]

jfj writes:
> The trust model is this: We suppose that malware is running.
> Suppose from a buffer overflow in libPNG which achieved
> priviledge escallation to root. It is OK for malware to run but
> it will not be able to connect to anyone.

What's the point in that?

If your fix becomes common practice, then attackers will just learn to
open /dev/kmem and rewrite the bits that are preventing them from
doing what they need to do.  Or more simply just overwrite a binary
that has the privileges desired, and exec that.

If your fix doesn't become common practice, then the problem (to a
large extent) hasn't been solved.

> Thus the attacker
> will be blind, he will never know that the malware is
> working and it will operate in isolation. Therefore,
> nobody will be able to *control* the host or *get* data from
> it. Sure, the running malware may delete everything :)
> 
> So the host may be compromised but it will be more like the
> good old viruses that were transmitted in the boot sector
> and didn't have a link to their creator.

As long as the system still has a network connection, and root remains
all-powerful, I think you're stuck with that problem.

I suspect that achieving what you describe really means reigning in
the power of root, so that even if someone gets access to UID 0, he
doesn't have access to the rest of the system, and drastically
reducing the scope of [bracketing] privileges, so that nothing that
requires additional privileges is ever using libPNG in the first
place.

-- 
James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>

Re: pppd security

[jfj]

James Carlson wrote:

>jfj writes:
>  
>
>>The trust model is this: We suppose that malware is running.
>>Suppose from a buffer overflow in libPNG which achieved
>>priviledge escallation to root. It is OK for malware to run but
>>it will not be able to connect to anyone.
>>    
>>
>
>What's the point in that?
>
>If your fix becomes common practice, then attackers will just learn to
>open /dev/kmem and rewrite the bits that are preventing them from
>doing what they need to do.  Or more simply just overwrite a binary
>that has the privileges desired, and exec that.
>
>If your fix doesn't become common practice, then the problem (to a
>large extent) hasn't been solved.
>  
>

In order for this to work is must not be common practice.
I'm trying to secure a very specific system. The logic is that it
will be a custom system where, for example, one must do a
couple of ioctl()s on a socket before it is activated. If the
ioctl()s are known, we've done nothing.

It is based on trying to predict what a malware would
attempt and sabotage it by adding non-standard calls.
Without feedback from the inside, the attackers work
will be quite difficult.

And if the malware tries too many things, it will be
detected sooner or later. (/dev/kmem disabled by
CAP_RAWIO)

Now I'm thinking about getting `struct ppp*` from `struct file*`
in ppp_open() and failing if n_channels is non zero. Sounds reasonable?

jerald