The server was fixed some time ago not to crash when a client sent
an os level string that was too long.  Server levels 3.1.2.20 and higher
should not crash because of the linux client.

(The mvs server apar number is PQ24311.)

--
--------------------------
--------------------------
Bill Colwell
Bill Colwell
C. S. Draper Lab
Cambridge, Ma.
bcolwell AT draper DOT com
--------------------------
In <BBC32887D5AFD211B3D100A02462006FBAEFB8 AT usrymx01.merck DOT com>, on 
10/18/99
In <BBC32887D5AFD211B3D100A02462006FBAEFB8 AT usrymx01.merck DOT com>, on 
10/18/99
   at 02:20 PM, "Purdon, James" <james_purdon AT MERCK DOT COM> said:

>Hi,
>   Buffer overflows of this nature can be used by an attacker to subvert a
>machine.  Now I am doubly dismayed.

>Jim

>> ----------
>> From:         Thomas Denier[SMTP:Thomas.Denier AT MAIL.TJU DOT EDU]
>> Reply To:     ADSM: Dist Stor Manager
>> Sent:         Monday, October 18, 1999 1:30 PM
>> To:   ADSM-L AT VM.MARIST DOT EDU
>> Subject:      Linux Client
>>
>> > Has anyone had experience with the linux client from the ibm site?  I
>> > have loaded it on a redhat linux 6.0 machine and am trying to connect to
>> > aix 3.2 adsm server.  The client is registered with the server and
>> > associated with a schedule but each time I try to connect from the
>> > client it crashes the server completely and I have to restart the
>> > server.  Any suggestions are welcome.
>>
>> The information sent from an ADSM client to the server at the beginning of
>> a
>> session includes an operating system version string. There is a limit on
>> the
>> length of this string (I think the limit is 14 characters). The Linux
>> client
>> sends whatever version string it gets from an operating system query, even
>> if
>> it exceeds the length limit. The server code (at least at older service
>> levels) does not check for the version string being too long; if the
>> string is
>> too long it overlays whatever storage follows the buffer allocated for the
>> version string. These storage overlays generally crash the server. I don't
>> know whether the server bug has been fixed in more recent service levels;
>> when
>> this problem was first discovered IBM insisted that the problem was purely
>> a
>> client bug and that there was nothing wrong with the server. You can
>> probably
>> circumvent the problem by switching to a Linux level with a shorter
>> version
>> identifier. If I remember the earlier postings on this topic correctly,
>> full
>> production releases of Linux have version identifiers that fall within the
>> limit, while test releases often have version identifiers that exceed the
>> length limit.
>>