all hacking aside ...
how i found this was some code passed @LOGNAME to a subroutine ( expecting
that read-only system variables would in fact be read-only ) which modifies
its input args.
after calling this routine everything from that point on that used @LOGNAME
was completely screwed -
log records / user id fields no longer contained valid user ids ,
programmatic security denied access to everything ,
user specific settings & validations when changing accounts bombed on
invalid user accounts ,
...
gerry
----- Original Message -----
From: "Allen E. Elwood (CA)" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, September 10, 2004 04:37 pm
Subject: RE: [U2] major (?) @var security hole
> Hi Gerry
>
> Wow! Looks like a bug to me. Submit it to IBM!
>
> However, having said that only programmer's would be able to do this, and
if
> you have a sneaky programmer there are many ways they could reek havoc
even
> without this bug. Sneaky programmers are almost always eventually
> discovered in balancing the books and loose their reputation; And with
> programmers, loss of reputation = loss of career.
>
> Most programmers good enough to be sneaky, know this, so I wouldn't worry
> *that* much.....
>
> Allen
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of u2ug
> Sent: Friday, September 10, 2004 12:34
> To: [EMAIL PROTECTED]
> Subject: [U2] major (?) @var security hole
>
>
> this may be common knowledge , but I stumbled across this yesterday at a
> client's site and was very surprised / alarmed.
> if you rely on system variables, @LOGNAME , @WHO in particular, for any
kind
> of security / access control , you may be interested to know that these
> 'static'/'read only' variables can very easily be modified to contain any
> values you like - including other user ids and account names.
>
> BP TEST
> 001: *******************************************
> 002: * verify current values
> 003: *******************************************
> 004: crt "Before : ":@WHO,@LOGNAME
> 005:
> 006: *******************************************
> 007: * direct modification of system variables
> 008: * - bombs in compile [EMAIL PROTECTED] (Read-Only) unexpected ...]
> 009* * - this is good !
> 010: *******************************************
> 011: * @LOGNAME="xx"
> 012: * @WHO="yy"
> 013:
> 014: *******************************************
> 015: * indirect modification of system variables
> 016: *******************************************
> 017: call SUB(@WHO,@LOGNAME)
> 018:
> 019: *******************************************
> 020: * verify current values
> 021: *******************************************
> 022: crt "After : ": @WHO,@LOGNAME
> 023:
> 024: end
>
>
> BP SUB
> 001: subroutine SUB(arg1,arg2)
> 002: arg1="xx"
> 003: arg2="yy"
> 004: end
>
> >WHO
> 1234 TESTACCOUNT From TESTUSERID
> >RUN BP TEST
> Before : TESTACCOUNT TESTUSERID
> After : xx yy
> >WHO
> 1234 xx From yy
>
> notice - not only are these @vars modified within the program but the new
> values are persisted into the prompt environment as well !!!
>
> anyone else see this as a <!!<!!<!!<MAJOR>!!>!!>!!> bug ?
>
> gerry
> -------
> u2-users mailing list
> [EMAIL PROTECTED]
> To unsubscribe please visit http://listserver.u2ug.org/
> -------
> u2-users mailing list
> [EMAIL PROTECTED]
> To unsubscribe please visit http://listserver.u2ug.org/
-------
u2-users mailing list
[EMAIL PROTECTED]
To unsubscribe please visit http://listserver.u2ug.org/
