Recent troubles

[mouse () Collatz McRCIM McGill EDU (der Mouse)]

First, about the loadable kernel module for spying on things.  Someone
writes

> In the more recent versions of [4.4-Lite-based OSes], I believe it is
> not possible to load a kernel module after it has left single user
> mode.  Does anyone know of a hack to SunOS which affords the same
> kind of `protection' ?  Of course, /dev/kmem & /dev/mem would need to
> become read-only devices too...

I intend to attack our SunOS kernels with an eye to doing just this.  I
don't know how soon I'll have anything....

And second, about TCP sequence number guessing.

> > This sounds to me like a serious problem.  The only real fix is to
> > make sure that your sequence numbers _are_ strongly random, which
> > without source is difficult at best.
> What I can't understand is why everyone is freaking out over this
> "new" hole when it's been around forever.

Speaking personally, I was aware of the theoretical potential but I had
no idea most (all?) kernels used such idiotically simple and easy to
predict methods to generate initial sequence numbers.  (Never read
smb's paper, obviously.)

I think that when I do the above hacking on our SunOS kernels, one
thing I'm going to do is throw a wrapper around ip_input, so that every
packet received is used to corrupt tcp_iss.  Probably something like
use tcp_iss as a CRC accumulator and feed the packet in...almost
anything will work, as long as it ensures a rapidly and unpredictably
changing value.

If I had source, I'd probably corrupt tcp_iss on not only received
packets but also keystrokes, inode fetches from disk, context
switches...almost anything could usefully be used.  Depending on the
clock is too weak.  (There is some risk of creating a covert channel
that can be used to discover useful information, such as deducing
keystrokes from initial sequence number changes.  In my opinion, the
risk of this is quite small, and with enough other things also
corrupting the ISS, it becomes vanishingly small.  Force enough "covert
channels" to funnel through the single 32-bit ISS variable, and they'll
conceal one another quite effectively.)

> > As a weak defense, you can make sure that the server->client
> > messages for your TCP services vary in length, so as to make it
> > impossible to carry on a complete conversation without seeing the
> > packets.
> I'm a little confused by what exactly you mean here (my ignorance
> shines through again.  :-) but it sounds intriguing, could you please
> illaborate?

The point of my remark was that the spoofer can't ack your machine's
output without knowing how many bytes to ack.  But this matters only if
it's necessary for the attacker to ack it, which is not the case for
many attacks; thus, on reflection, it's an even weaker defense than I
thought.  It helps only for services where the connection is long-lived
and/or generates a lot of output, because otherwise the connection can
be created, used, and killed with the generated output still sitting
un-acked in the socket's send queue.

                                        der Mouse

                            mouse () collatz mcrcim mcgill edu