In the Land of the Blind, the Hoff is truly King!

Hi Dave,

"Dave Froble" <davef@xxxxxxxxxxxxx> wrote in message
news:ZumdnXXX0vajcpfYnZ2dnUVZ_t2dnZ2d@xxxxxxxxxxxxx
Is that a tease? I'm sure I'm not the only one following this thread.
Some of us may be interested in what caused the problem. Since you say
it takes priviledge to cause the crash, you wouldn't be causing a
problem in going public with what you found.

I can't promise you an answer but FWIW here are my thoughts on what may've
happened. (Given the reported truth and integrity vacuums that appear to be
prevailing, this is probably the best you'll get. I can't tell you whether
my theory it's right or wrong (until the next source code release), but if
you (or anyone) can tell me why it's not possible, or correct, then I'm
happy to have another look at it.)

[Or I could just wait for the dump to complete again, and see if I can
convert the System Dump PC into the line number/address in the VMS source,
or reverse engineer the last macro-64 instructions into their Bliss
counterparts; that too would be good :-) Must be a Fine Manual around here
on Reading a System Dump.]

In the meantime: -

1) As reported, an item list to $audit_event (when left un terminated) was
observed to crash the system from User Mode code.

2) On Planet Dickie, Item Lists are passed By Reference, therefore I believe
that everything following the Audit_List in the same Cobol PSECT up to the
first occuring aligned or coded zero-lognword (in the correct terminator
offset) will be processed by $audit_event in situ, and that something in
that compiler initialized memory is causing the problem

3) I wrote a subroutine to mimic the Item_List parse by receiving the
Item_List By Reference and dumping out its contents until I found a valid
terminating longword. (The complete output of which is below. As you can
see, my program says there are now 27 item list entries rather than the
expected 12) "

4) If my theory was correct then item 13 (unlucky for some :-) should fail
any validation check 'cos surely 20526 is greater than nsa$_max_itm_code
which is 279 on my box but 283 on later versions. For those of you ASCII
buffs, I once again submit that this is the contents of audit_object_name
(ie: St.Peter blah blah . . . all the way to the end of the Uai_List.)

5) As a test, I added these items to the end of the Audit_List after
Item_Time_Stamp: -
03 item_crash.
05 pic s9(4) comp value 29779.
05 pic s9(4) comp value 20526.
05 pic s9(9) comp value 1919251557.
05 pic s9(9) comp value 1953841440.
03 item_terminate pic s9(9) comp.
And guess what? It still crashed; so I think we're doing ok so far! Off to
look at the code again.

6) If you look at the nsa$size_nsab routine in security_auditing_64.lis at
line 1085, you will see that it does in fact check that the item code is in
the valid range of 1 to nsa$_max_itm_code. So why isn't that simple IF
returning ss$_baditmcod?

7) Hold everything! What do we have lurking up there at line 1079? Could it
be: -

if .nsa$validate_table[.item_code, itm_size_min] eql ignore

But if nsa$validate_table is only nsa$max_itm_code big, then what happens if
VMS engineering attempts to reference element (20526)???

Elsewhere in the source lines (711, 721) and nsa$itmlst_to_pktlst (283) the
order of the checks is reversed, as expected. But what about the comment on
line 101 on 20-Nov-1997 "Reorder parameter checking to avoid bogus array
index values in NSA$SIZE_NSAB."

Unfortunately, I don't have the resources to assemble the previously
convened dream-team of Hoffman, Plato, Socrates, Da Vinci and Einstein to do
a code review, but at face value (at least to me) it looks decidedly fishy
to do a table lookup for an element before validating that the subscript is
in range. Maybe Bliss needs some /CHECK=BOUNDS trainer-wheels?

But I don't know Bliss so maybe it just knows, and I'm jumping the gun
again. If only John Reagan hadn't been bound, gagged and thrown in the
basement then *he* could've told us :-( Off to find another Bliss person. .
..

8) A mate tells me that the "uplit" part of the nsa$validate_table
declaration materializes it in a read-only Psect at compile-time. (Just like
Macro and Cobol can. These 3 great languages have much in common!) So I'm
guessing that the "ignore" flag lookup for item list entry 13 with just
calculate an address that is nsa$validate_table+(20526*bytes_per_entry) and
try to read it. Couldn't see enough after nsa$validate_table in the listings
to cover it so that probably explains why it varies from sysgen parameters
to machines to quotas to . . .

Anyway, the footy's back on and the Eagles are getting thrashed (were
consistent over here :-() Let me no if it doesn't stand up or if you like
it.

If you think of it, I can't be right because this would warrant an urgent
fix as *any* call to $audit_event is now a time-bomb just waiting for a user
mode ponter to set it off. Or is it a case of "She'll be right"? hasn't
happened all these years and we don't want to panic anyone with another
security release. (Anyone seen the release note for $create_user_profile and
the user-mode corruption of exec-mode memory? Nah must've been dreaming
there too.)

YES, This is all tongue in cheek! If it is a bug then it's just that; a bug!
Fix it and move on - no big deal. I've gone out of my way to sound like a
pompous arse here (not much trouble really :-) because that is what your
superior, arrogant, self-indulgent crap sounds like.

Cheers Richard Maher

NB: I must stress at this point that no thorough review of any VMS source
code including, but not limited to, $audit_event and any subroutine it
invokes, has taken place. I do not offer any opinion as to the
merchantability of said software nor to its fitness for any particular
purpose. If I have identified a bug then all well and good (and soon may it
be fixed) but I by no means warrant that is the last bug in these modules,
nor that the probing of arguments covers multiple page boundries, an yadda,
yadda yadda. . .

PS. Anyone see bits of the Steve Irwin memorial the other day? When John
Williamson sang Steve's favourite song? You used to be able to hear it ring
out through the suburbs after a bbq when the blokes had had just enough beer
that they'd start babling and telling everyone just how much "I love yous!"
(In a Perth sense and not the Sydney sense :-) Anyway, you don't hear it
much anymore and I for one had to wipe away a tear!

Is it standin by your mate
when he's in a fi-ight?
Or just "She'll be right"?

Tru-oo-oo-blue, I'm arrrskin YOUUUUU!

Item_list Dump: -
Item (1) code = 89 len = 4 addr_1 = 000200A0 addr_2 = 00000000
Item (2) code = 90 len = 4 addr_1 = 000200B8 addr_2 = 00000000
Item (3) code = 3 len = 8 addr_1 = 00020228 addr_2 = 00000000
Item (4) code = 6 len = 8 addr_1 = 00020228 addr_2 = 00000000
Item (5) code = 189 len = 16 addr_1 = 00020218 addr_2 = 00000000
Item (6) code = 29 len = 31 addr_1 = 000201F8 addr_2 = 00000000
Item (7) code = 48 len = 4 addr_1 = 00020150 addr_2 = 00000000
Item (8) code = 192 len = 4 addr_1 = 0002035C addr_2 = 00000000
Item (9) code = 190 len = 4 addr_1 = 00020028 addr_2 = 00000000
Item (10) code = 56 len = 6 addr_1 = 000204F4 addr_2 = 00000000
Item (11) code = 80 len = 6 addr_1 = 0002051C addr_2 = 00000000
Item (12) code = 50 len = 8 addr_1 = 00020300 addr_2 = 00000000
Item (13) code = 20526 len = 29779 addr_1 = 72657465 addr_2 = 74754120
Item (14) code = 29806 len = 25960 addr_1 = 74616369 addr_2 = 206E6F69
Item (15) code = 30322 len = 25939 addr_1 = 00207265 addr_2 = 61746544
Item (16) code = 25701 len = 26723 addr_1 = 6F725020 addr_2 = 73736563
Item (17) code = 21827 len = 17747 addr_1 = 59544952 addr_2 = 00160001
Item (18) code = 2 len = 672 addr_1 = 00000000 addr_2 = 00150002
Item (19) code = 2 len = 680 addr_1 = 00000000 addr_2 = 00120008
Item (20) code = 2 len = 720 addr_1 = 00000000 addr_2 = 00130008
Item (21) code = 2 len = 728 addr_1 = 00000000 addr_2 = 00230004
Item (22) code = 2 len = 688 addr_1 = 00000000 addr_2 = 00190008
Item (23) code = 2 len = 744 addr_1 = 00000000 addr_2 = 00140002
Item (24) code = 2 len = 840 addr_1 = 00000000 addr_2 = 001E0008
Item (25) code = 2 len = 760 addr_1 = 00000000 addr_2 = 001D0008
Item (26) code = 2 len = 752 addr_1 = 00000000 addr_2 = 00000000
Item (27) code = 0 len = 3 addr_1 = 00000000 addr_2 = 0000E95C


"Dave Froble" <davef@xxxxxxxxxxxxx> wrote in message
news:ZumdnXXX0vajcpfYnZ2dnUVZ_t2dnZ2d@xxxxxxxxxxxxx
Hoff Hoffman wrote:

As it happens, the working theory was not the actual trigger here (data
often has a habit of derailing theories), but what was recently posted
had sufficient data within to allow the identification of the specific
trigger from amid all the stack detritus that was located after the
(missing) termination within your particular OpenVMS run-time
environment.

Is that a tease? I'm sure I'm not the only one following this thread.
Some of us may be interested in what caused the problem. Since you say
it takes priviledge to cause the crash, you wouldn't be causing a
problem in going public with what you found.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@xxxxxxxxxxxxx
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486


.

Quantcast