pppd security

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

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         <[email protected]>

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

Yes.

That's right.

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.)

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

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         <[email protected]>

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

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.

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         <[email protected]>

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