Re: Re: Recent bugtraq postings

These are my opinions only. They do not necessarily reflect the opinions of 
my employer...

Just a couple examples of inaccuracies

   1. Claim: The LDAP server on OS400 provides information about userIDs 
   on OS400. The LDAP server is started automatically. Both are true.
   Implied by the posting: OS400 will provide anyone who knows how to 
   talk to an LDAP server information about user profiles on the system. 
   False/wrong/inaccurate.
   
   
   Clarification: OS400 in general -- not LDAP on OS400 -- allows a 
   person to see those user profiles to which they are authorized on a specific 
   system. The LDAP server provides the same information that other OS400 
   interfaces will provide based on authorization. 
   
   This is NOT a problem related to LDAP and characterizing it as such is 
   inaccurate. This is an architected and documented behavior of the system -- 
   not for LDAP but for any interface related to list user profiles that exist 
   on the system. Sending people off to look for an LDAP exposure wastes time 
   and energy and takes focus away from things they could be doing to manage 
   the security on their systems better.
   
   The LDAP server is started by default, however, unless it has some 
   PUBLIC information stored in it (access allowed to anyone that binds), there 
   is nothing to see. The fact that an authenticated OS400 user can see the 
   same information through LDAP that they could see through any other non-LDAP 
   interface to look at the same type of data does not necessarily constitute a 
   security exposure.
   
   The recent public postings implied that not only is the LDAP server 
   started by default, but that somehow the information about other profiles on 
   the system is available to anyone that knows the TCP/IP address of the LDAP 
   server. Only authorized OS400 user profiles are allowed to access the 
   "projected user profile" LDAP back-end. Even when authorized the profiles 
   can only see those other profiles to which they are authorized.
   
   If one doesn't agree with the documented behavior, then they should 
   provide the necessary information to the vendor (not to mention read the 
   documentation which is on-line in the information center). I personally do 
   not consider this a security exposure; however, if you believe it is no 
   longer considered appropriate then work to change it through the vendor who 
   is the only one that can. Publishing inaccurate information in a public 
   forum is not an efficient way to influence change.
   
   
   Again, seeing any data to which you are authorized is not considered a 
   security exposure. On OS400, as opposed to those systems you might actually 
   use, user profiles are separate objects (it's an object-based OS). Since a 
   user profile is an object you have a level of authorization control over 
   them that is not typically available on other systems.
   
   Because the public announcement only noted the LDAP server, a lot of 
   people went on a hunt to try to find something they were not likely to find. 
   
   
    2. Claim: OS400 has a security exposure because a bad person could 
   use commands on OS400 to do bad things on Windows.
   Implication: OS400 causes the exposure.
   Clarification: The fact that you can use information from a connection 
   established by windows to perform windows commands unrelated to the 
   connection is not an exposure of another system that "COULD" take advantage 
   of it. It is a windows exposure. It's something that needs to be managed or 
   fixed in Windows.
   
   Announcing it as an OS400 exposure is inaccurate and helps no one 
   address the real "issue." The implementation of commands on OS400 use the 
   same mechanisms on the windows side as could be used from any other system.
   
    3. Claim: IFS is not protected by 3rd party vendor products...
   Implication: IFS cannot be protected. Whether intended or not, this 
   was the implication, and this is totally false.
   The short description of IFS implied that by it's mere existence on 
   OS400, that there was some kind of "undesirable" security attribute. It is 
   easy to use OS400 as a file server for windows, but it can just as easily be 
   configured to only share files in a particular part of the IFS file system 
   tree or subdirectory of a particular file system tree.
   
   Is it possible to incorrectly file server more files than intended? 
   Yes. Is this a security exposure for the system? No? Is it a security 
   exposure for 3rd-party applications? I don't know, because since I don't own 
   or use those applications, I cannot be certain how 
   they are configured and if they are configured correctly. However, it 
   is not clear that if the observed behavior was related to exposures in 3rd 
   party products or due to the way a particular implementation of one or more 
   of those products. Without a copy of the product and documentation, I don't 
   see how anyone could ascertain whether observed behaviour is an inherent 
   exposure in the product. At best, one should clarify whether they have 
   actually tried each product AND whether the problem was known NOT to be a 
   configuration problem.
   
    4. Claim: "IBM refused several times to answer my queries about some 
   of the
   issues. I was asked to supply a valid service agreement before anyone
   would talk to me."
   Implication: IBM will not accept input related to security exposures
   Clarification: The IBM support line DOES accept input related to 
   security exposures. If you do not have a support line agreement you can only 
   use the interent interfaces; you are not entitled to phone support. 
   
   There is no way IBM could provide phone support to customers that 
   actually pay for their systems and presumably understand how their system is 
   configured if they spent time with those people who haven't apparently 
   purchased a system.
    
It is irresponsible, in my opinion, to publicly report a security exposure 
when one does not totally understand the system or applications for which 
they are reporting an exposure. It is also irresponsible not to get 
independent verification of a suspected exposure -- especially if one does 
not even know how the system being tested is configured with respect to 
security.

I don't see how it is possible to determine whether a security exposure is 
inherent to a whole class of systems or merely due to the way a particular 
system is configured or managed if you don't have access to someone who can 
report an APAR. To not mention in public postings that the vendor was not 
notified because you are not a customer is also misleading, in my opinion.


On 25 Apr 2005 15:59:14 -0000, shalom@xxxxxxxxxx <shalom@xxxxxxxxxx> wrote:
> 
> Michael,
> I can live with assumptions, but what in your opinion is inaccurate?
> 
> Shalom Carmel
> -------------
> www.venera.com <http://www.venera.com> - Exposing iSeries insecurity
> 
> Michael Crump said:
> > Suffice to say, not sure if I would call them lies
> > but there are assumptions and inaccuracies.
> 
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing 
> list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
> 
>