Re: The disappearing sys_call_table export.

Muli Ben-Yehuda (mulix@mulix.org)
Sat, 10 May 2003 22:53:20 +0300


This is a MIME-formatted message. If you see this text it means that your
E-mail software does not support MIME-formatted messages.

--=_courier-20333-1052596473-0001-2
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, May 10, 2003 at 10:18:34PM +0300, Yoav Weiss wrote:

> Masud, your delay-based solutions won't work because an attack code can
> just keep running in a loop until it gets the timing right. Once is
> enough. Even if it could work, it would have impact on the whole system.
> Afaik, you can't really yield the CPU for very short time slices so you'll
> have to busy-loop instead, and its not acceptable. I believe the below
> solution is the right one. Arjan, please correct me if I'm wrong.
>=20
> The solution is to have only ONE REAL copy, done by the wrapper. The
> original syscall will copy from a kernel ptr, unknowingly. Consider
> the following modified pseudo-code:
>=20
> long your_wrapped_syscall(char *userfilename)
> {
> char kernelpointer[something];
> copy_from_user(kernelpointer, usefilename, ...);
> audit_log(kernelpointer);
> old_fs =3D get_fs();
> set_fs(KERNEL_DS);
> ret =3D original_syscall(kernelpointer);
> set_fs(old_fs);
> return ret;
> }
>=20
> userfilename is only copied once. original_syscall just copies
> kernelpointer again, to another kernel pointer. No race.

This approach, while it would solve this particular problem, has a
grave flow. Consider the case where the first copy in the
original_syscall is to copy a user space structure, which has embedded
user space pointers... The set_fs() will cause future
copy_from_user/copy_to_user in original_syscall() calls to succeed
even if the user supplied pointer is in kernel space.=20

> Removing this symbol will not really get in the way for the bad guys
> because it'll always be possible to find and intercept it anyway (see my
> previous post in this thread), but it'll increase the learning curve for
> kernel newbies. Do we really want that ?

Hear hear.=20
--=20
Muli Ben-Yehuda
http://www.mulix.org

--=_courier-20333-1052596473-0001-2
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE+vViwKRs727/VN8sRAoHjAJ9GCweHBvllLXvFZZk1l1tHCH3tnwCeP1UD
LiRFJRq1EJ8nKUsMZbNNBeY=
=Rfoo
-----END PGP SIGNATURE-----

--=_courier-20333-1052596473-0001-2--