| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 55.1 | | ORPHAN::BRETT | | Sun Sep 09 1984 03:15 | 10 |
|
Lots - just physical access to the console [[halt machine, mung privilege mask,
continue]], physical access to the system pack [[mung UAF]], SYSNAM [[stick
a great logical in the system logical name table and wait]], PHYS_IO, LOG_IO
[[mung UAF]].
And if you are really clever, none. Just find a security hole in some critical
code [[still haven't found one in V4 FT2 but that doesn't prove its not there]].
/Bevin
|
| 55.2 | | LATOUR::AMARTIN | | Sun Sep 09 1984 13:04 | 4 |
| Does VMS log events like use of SETPRV, or modifications (pokes) to the monitor
yet? Once it does, you have to be good enough to get into the log file and
cover up the traces.
/AHM
|
| 55.3 | | VIKING::WATERS | | Sun Sep 09 1984 18:50 | 7 |
|
What about world read access to SYSUAF? Any hashing algorithm that is
"one way" means that traceback information is lost. Therefore, more than one
password can hash into the same thing. Who knows the hashing algorithm?
Just plug in words until you get a match. Yes, its gross and old fashion...
/lw
|
| 55.4 | | NY1MM::MUSLIN | | Mon Sep 10 1984 07:59 | 4 |
| DETACH - you can detach a process with any uic - detach with [1,4] and
give it a command procedure that sets your privs in SYSUAF.
- Victor -
|
| 55.5 | | ORPHAN::BRETT | | Mon Sep 10 1984 19:38 | 9 |
|
Re .3 - the whole point of the current hashing algorithm is it is VERY CPU
EXPENSIVE to invert this way, the algorithm is deliberately expensive in
computes to apply and is apparently very difficult to invert. The main
danger with W:R SYSUAF is it gives a list of user names, thus cutting down
the number of possibilities that you have to try to find some person who
does not have a difficult-to-guess p/w.
/Bevin
|
| 55.6 | | HARE::COWAN | | Mon Sep 10 1984 20:07 | 6 |
|
How about PFNMAP. I believe it is possible to map to a
certain set of phyical pages and watch the terminal I/O. This would
mean you could watch someone type in the password.
KC
|
| 55.7 | | PARVAX::PFAU | | Tue Sep 11 1984 04:38 | 4 |
| The description of $CMKRNL says that the user needs CMKRNL privilege
or must be running in executive mode. So how about CMEXEC?
tom p
|
| 55.8 | | SPARTA::KENAH | | Tue Sep 11 1984 13:13 | 19 |
|
The answer to the original query is already published in the
documentation. (See Chapter 4 of the VAX/VMS System Management
and Operations Guide.) The privileges listed in the category
called "All" are effectively the keys to the kingdom. That is,
given any one of the "all" privileges, it is a trivial matter
to obtain any privilege or do any sort of nasty deed to the
system.
The real intellectual exercise is to determine whether some of
the privileges listed in the more benign categories are, in fact,
more dangerous than originally supposed.
(Note that a positive answer to this question should NOT be posted
in this or any other notes file but should be quietly reported
to the VMS development group so that the problem can be
dealt with.)
larry kenah
|
| 55.9 | | NIMROD::JER | | Fri Sep 21 1984 23:35 | 16 |
| Re .8: CMEXEC is almost equivalent to CMKRNL, since you are allowed
to switch to K whil in E. The following code gives you CMKRNL priv if you
have CMEXEC (mac +lib.mlb, and link with sys.stb):
.entry do_it,^M<>
$cmexec_s routin=e_mode
$exit_s
.entry e_mode,^M<>
$cmkrnl_s routin=k_mode
ret
.entry k_mode,^M<>
insv #1,#prv$v_cmkrnl,#1,@#ctl$gq_procpriv
ret
.end do_it
jer
|
| 55.10 | | WKRP::LENNIG | Dave, SWS, @CYO Cincinnati | Fri Oct 24 1986 22:00 | 3 |
| re.9 If all you're interested in is privs, your routine simply requires
the $cmexec and a $setprv.
|