× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Hi Patrick

While I don't disagree with your general point that allowing access to data to an authorised user cannot be considered a security exposure inherent in the system, I think on the whole I have to agree with Rob here; I, too, appreciated hearing about this method of circumventing security. Security that can be circumvented would seem to me to be fairly termed an exposure. The view I take is that in this case the access methodology is not an "approved" access method and that the intent has been to lock it down using an exit point to control access.

Unless I read it wrong, the identified exposure reveals how the intended exit point restriction can be evaded by manipulating the path to navigate to supposedly forbidden directories unless this has been explicitly catered for in the exit point program code. The API manuals as I recall them do not provide any guidance as to how to code for this type of path manipulation and in some eyes this might be considered a weakness or oversight.

Due to this, it seems to me that this is a useful thing to be aware of, particularly when trying to lock down a system that has a weak security model such as many iSeries shops have for historical reasons of relying on menu based security. The usual approach to trying to secure a machine with one of these security models is to use the exit points to overcome the inadequacies of the menu based strategy.

I do agree that the optimum solution is to move to a better security model but for many sites this is not always practical.

Regards
Evan Harris

At 11:04 a.m. 17/05/2005, you wrote:
I agree that telling customers that the only way to effectively control
access to data on the system is by using the native object access control
mechanisms is a very useful service. The fact that many customers don't is a
HUGE and very serious issue.

I do believe, however, that the author either by design or by accident
incorrectly identifies the source of the problem. Announcing every user
interface that can be used to access data by an authenticated and
authorizeduser is a disservice. The author's language is such that he
focuses on the
interface used to access authorized data rather than the fact that all
authenticated users are allowed to access most data.

This is not a security exposure inherent in the system. It is an exposure in
either the customer's security policy or his/her implementation of it. Yes,
it's a huge problem, but there is nothing the system can do to prevent an
authenticated user from accessing data to which he/she is authorized.

If the author would focus on publicizing the real issue, the greater the
likelihood that fewer people will be confused and ignore the warnings.

On 5/16/05, rob@xxxxxxxxx <rob@xxxxxxxxx> wrote:
>
> Frankly I think it was a good service to publish this so that I may fix my
> code. And, yes, users who are supposed to ftp files from/to our 400
> should have ftp access. It isn't that hard to write a program to lock
> this down. But with "heads up" notifications from people like this, you
> can fix it before someone exploits your mistake.
>
> Rob Berendt


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.