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

Hi Ian,

have you read this?

You've posted so many pointers to it up and down the web (And in Wednesday's
Evening Standard, I believe) that it would be almost impossible not to have
stumbled across it :-( How about posting a pointer to my reply with the
answer in it, for those who seek more the technical details and facts rather
than another opportunity to worship at the feet of their guru?

Yes, I read it (all 10 fact-devoid volumes of it) and found it to be the
greatest work of fiction since Saddam's WMD enquiry! (You should get Hoff
working on the Iranian report. You'd be "nuking those towel-heads" in no
time.) At least to me, the Mills and Boon prose betrayed a naivety usually
found only in one with very little development access to a keyboard.

"As for the resolution of the failure, a small reorganization to the
$audit_event[w] source code has blocked the particular exposure and the
vulnerability within the itemlist processing, and this change has been
implemented within the source code pool for OpenVMS."

sounds like what you are describing (doing validation in the wrong
order) is parhaps correct.

You're right! I added *no* value and introduced *no* new information and
just regurgitated what Hoff had already said. I've included *my* post below
so everyone can see how clever Ian was in sussing it. Hoff said "Something
has changed to fix it". It's pretty hard to argue with that. EXCEPT that he
made the fatal mistake of naming the code to be changed. Confidence must've
been high that if $audit_event was causing the bug-check then this is the
code that would be changed, but if I was right and the subscript
out-of-range bug with nsa$validate_table was causing the crash then the code
to be changed would be nsa$size_nsab and *not* $audit_event. "Splitting
Hairs" you might say? Well this is where I usually slipp into a couple of
paragraphs of self-indulgance and wax lyrical about modular programming
techniques as if you're all dickheads, but I must end the digression. If
nsa$size_nsab *is* causing the crash then it can also be caused by $chkpro
and $check_privilege that thankfully also seem to need Audit privs.

But before I rush out the door let's look at a few other things Hoff had to
say (the varacity of which I leave as a conundrum for the reader):-

The OpenVMS code review also showed nothing remarkable,
the contents of the itemlist were apparently verified.

In the case of the failing $audit_eventw call, it was literally
the specific detritus on the stack -- the random data bytes
in the right spot in the right range of addresses just after the
(missing) end of the itemlist got just far enough into and
just past the existing itemlist verification.

into what amounted to random data.

When the itemlist processing hit the particular (and
effectively the "just wrong") detritus,

In this case, it was the "just wrong" data after the end
of the unterminated itemlist, and data that's not deterministic.

Cheers Richard Maher

PS. How's your question about Shareable image SOGW protections coming along
Ian?

"Ian Miller" <ijm@xxxxxxx> wrote in message
news:1159290851.627324.38710@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
have you read this?

http://h20325.www2.hp.com/blogs/hoffman/archive/2006/09/16/1609.html

"As for the resolution of the failure, a small reorganization to the
$audit_event[w] source code has blocked the particular exposure and the
vulnerability within the itemlist processing, and this change has been
implemented within the source code pool for OpenVMS."

sounds like what you are describing (doing validation in the wrong
order) is parhaps correct.

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


.