[13962] in bugtraq
Re: unused bit attack alert
daemon@ATHENA.MIT.EDU (Jochen Bauer)
Tue Feb 22 20:35:03 2000
Mail-Followup-To: bugtraq@securityfocus.com
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-md5;
protocol="application/pgp-signature"; boundary="BOKacYhQ+x31HxR3"
Message-Id: <20000222115409.A29641@luna.theo2.physik.uni-stuttgart.de>
Date: Tue, 22 Feb 2000 11:54:09 +0100
Reply-To: Jochen Bauer <jtb@THEO2.PHYSIK.UNI-STUTTGART.DE>
From: Jochen Bauer <jtb@THEO2.PHYSIK.UNI-STUTTGART.DE>
X-To: bugtraq@securityfocus.com
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <200002211543.HAA24775@www.geocrawler.com>
--BOKacYhQ+x31HxR3
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
On Mon, Feb 21, 2000 at 07:43:54AM -0800, LigerTeam wrote:
[...]
> In fact, TCP header is 6 kinds of
> tcp flag (SYN, ACK, PSH, RST, FIN, URG).
>=20
> problem is the flag value in TCP header
> approaches to 1byte variable of u_char type.
> ex)see tcp.h file
>=20
> The flag value Each one correspond to 1 bit,
> but it have unused 2 bit.
>=20
> |unused|unused|URG|ACK|PSH|RST|SYN|FIN|
>=20
> Understanding of the very problem is simple.
> Let's compare the two codes.
> ex)SYN Scan detecter program several code type
>=20
> i) if ( flag =3D=3D TH_SYN )
>=20
> ii) if ( flag & TH_SYN )
>=20
> (TH_SYN->SYN flag)
>=20
> The i) code is true, only when the syn
> flag bit is set at 1.
>=20
> So the flag value is 0x2,
> and |0|0|0|0|0|0|1|0| in bit.
>=20
> The next ii) code is true, only
> when SYN flag bit, the TH_SYN value
> in flags, is set at 1, and the other
> bit state is not influential.
>=20
> Eventually, we can easily know a very
> important thing.
>=20
> If hackers use the two higher bit(unused bit)
> one or all, to set at 1,
> ii) code type has false value,
> but i) code type last true value.
> and hackers avoid scan detecter
[...]=20
> Conclusion:
>=20
> When the flags variable in tcp header is adjusted
> totally with given value,
> higher two bit(unused bit) must be cleared
> and set at 0.
[...]
This is a known issue; it's in the category of "invalid TCP flags=20
scanning". In fact, the two unused bits in the TCP flags byte can=20
be used for TCP fingerprinting as the response to such TCP packets=20
is not specified in RFC 793 and therefore depends on the TCP/IP=20
implementation being used. In addition to TCP fingerprinting, TCP=20
packets with certain invalid (i.e. not covered by RFC 793) flag
combinations not including the SYN flag can be used to determine=20
which ports are open on the target machine.
This leads one to the conclusion that focussing on TCP packets with=20
the SYN flag set is completely insufficient for scan detection. Any=20
decent scan detector must, among other things, pay explicit=20
attention to those 2 unused bits in the TCP flags byte anyway.
--
Jochen Bauer
Security Team (RUS-CERT) =20
Computer Center of the University of Stuttgart =20
Germany
=20
************************************************************************=20
*Email: jtb@theo2.physik.uni-stuttgart.de *
* jochen.bauer@rus.uni-stuttgart.de *
* *
*PGP Public Key: *
*http://ca.uni-stuttgart.de:11371/pks/lookup?op=3Dindex&search=3D0xB5D92889*
************************************************************************=20
--BOKacYhQ+x31HxR3
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
iQEVAwUBOLJq0Fthq5K12SiJAQFVwQgAqc1my6msmPqNHC8nM+3XrBsye525N6oK
Ee1ujB7dey1Y0fhobxkLiKzoLl2OHtaVU4QRI4Mgl7w9pRBay4wjjZIVyu1M4JEp
SoJ0xj6XGezHDvIJo5tF1qpkSRFlicmmEVmBZwVA8bEuu7JkdRpL2QsYk+x6w3Dk
uft4GG9TPzmvfVc6EkHtbfllyIFQymkz/XFxkpBagkpz2cny5WdoSJSSbw9VspbW
K18SrWhvxequctDHFGUJIU7tluJpzX7nOF6VnEly7MNuj7Gfb1cU5+Lg8ExvPTlm
v9xbW1vAXdfJVhSEKt001kwElUiAvXBbJKZ3kXhfQrQid+fslzgEig==
=/VRH
-----END PGP SIGNATURE-----
--BOKacYhQ+x31HxR3--
