On Monday, April 11, 2022 at 11:42:00 PM UTC-7, Johnny Billquist wrote:

(snip, I wrote)
> > Disk files on Unix-like systems and DOS/Windows are just a string of bytes.
> > Any block structure is hidden by the OS disk cache.

> Well, it's not hidden by the OS disk cache in Unix. It's hidden by the
> device driver framework. That's where the block and character devices is
> about.

If you do a read() system call on a disk file, it either fills the buffer or
writes the bytes left in the file. There used to be a rule that you should
never use the block disk device. That restriction might be gone, but I
am not sure what happens if you do use it. When I do write raw disk
devices, I use the character device.

> > On the other hand, tapes on Unix, and I believe DOS/Windows do have a block
> > structure. In some cases, it is necessary to preserve that in order to
> > properly read them. There are virtual tape formats that convert a tape of
> > blocks into a stream with block marks included, and others to reverse it.

> Actually, in Unix, tapes are the same story as disks. However, no sane
> person ever cared to use the character device for tapes, since (as you
> observe), with tapes there are additional reasons why you want to know,
> and preserve block information. The character device hides this from you.
All the Unix tape work I ever did was with the character device.
Maybe 20 years ago, we did it with tar, where you tell tar the blocking
factor that you want, and it writes blocks of that size to tape.

The Unix read() system call on a tape character device returns one tape
block, and the length of that block. On 9-track reel tape drives that I know,
you can write any block length you want, with the drive writing the block,
and an inter-block gap to the tape. Some other tape systems only allow
for fixed sized blocks.

More recently, I was working with Ultrium (LTO) drives, which have two
modes. In one mode, the drive writes fixed length (usually 512 byte)
blocks, the other looks more like 9-track drives. Though in the case
of LTO all the blocking is virtual. Having the drive in the wrong mode
confuses programs like tar.

> For networking, it's all carried by IP datagrams in the end, which are
> blocks. TCP then implements a stream of bytes abstraction on top of that.

Yes, but TCP won't tell you were the boundaries were before the data
went into the TCP stream, or where the IP boundaries were.

On Monday, April 11, 2022 at 8:00:45 AM UTC-7, Dennis Boone wrote:

> > That is obviously incorrect. Every disk used today is divided into
> > blocks. So that is what a file on a disk is, in the end. And that is not
> > the same as a string of bytes. The string of bytes abstraction is
> > implemented on top of this.

> Er, not a very convincing argument. In that vein, every magnetic media
> disk used today is a string of flux transitions. The bytes and blocks
> abstraction are implemented on top of this.

Blocks are real on floppy disks, even today. (Well, they might not be
so easy to find.) I suspect, though, that on the usual hard disk these
days, that blocks might be mostly virtual.

Traditionally, the important part of disk I/O is the write splice, where
one starts and stops writing a block. The controller/drive has to
start writing just after the appropriate block header, and stop within
the gap after the block. But as internal disk buffers got bigger, it is
now possible for a whole disk track to go into the buffer. Though
last I knew, disks knew how to start reading in the middle of a track,
such that it could supply blocks to the system before reading the
whole track.

Some earlier drives are likely still running, though.

Note that the rotational speed of disks hasn't changed much over
about 50 years, and rotational latency is a big part of disk reading.

On 2022-04-11, VAXman- @SendSpamHere.ORG <VAXman-@SendSpamHere.ORG> wrote:
> In article <t31ose$pr0$1@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>
>>Ok, Brian, you win. I'll be pedantic if you wish. :-)
>>
>>Once you have code you control running in one of the hardware inner modes,
>>you can get to the others without any additional privileges required on
>>the part of the account doing it.
>
> NOT TRUE. Stop confusing $CMKRNL from EXEC mode with all others. You can
> NOT get to EXEC from SUPERVISOR mode. Granted, you found an exploit with an
> installed image but that was corrected. There's no $CMEXEC jump from SUPER-
> VISOR mode without privileges vis-a-vis $CMKRNL from EXEC mode.
>

You are contradicting yourself with the above statements Brian.
First you say it's not possible, then you say it's possible if the
supervisor mode code has access to the privileges of the current image.

As you have been told multiple times Brian, the only fix was to fix
the buffer overflow that allowed me to get code running within the
context of DCL itself. There was nothing fixed to reduce what you can
do once you are in supervisor mode.

If someone finds another way back into supervisor mode, then supervisor
mode is still as dangerous as it always was.

For anyone else wondering why supervisor mode is so dangerous, it's
because code running in supervisor mode has access to the privileges
of the current image.

You are really only limited by your knowledge and imagination with what
you can do with that. There are two ways I know of to make use of that:

1) The CTRL-Y attack which was part of my exploit.

2) You can activate a privileged image from supervisor mode and then
use its privileges. You don't have to take my word for this one as
the image activation sequence is very well documented in the Alpha I&DS
manual.

If you read the image activation checklist in the Alpha I&DS, you will see
that the image activator enables the image's privileges in the current
process and _then_ returns control back to DCL with those elevated
privileges in place.

So yes, if you have code that you control running in supervisor mode,
then you can still use it to get into executive or kernel mode.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2022-04-12, gah4 <gah4@u.washington.edu> wrote:
> On Monday, April 11, 2022 at 11:42:00 PM UTC-7, Johnny Billquist wrote:
>
>> For networking, it's all carried by IP datagrams in the end, which are
>> blocks. TCP then implements a stream of bytes abstraction on top of that.
>
> Yes, but TCP won't tell you were the boundaries were before the data
> went into the TCP stream, or where the IP boundaries were.

I wonder if there are any programmers still around that try to
treat TCP as if it was record based anyway. :-)

I know that in the old days, you sometimes came across reports of
people that assumed one TCP write in a program turned into exactly
one read in the receiving program...

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2022-04-12 10:44, gah4 wrote:
> On Monday, April 11, 2022 at 8:00:45 AM UTC-7, Dennis Boone wrote:
>
>>> That is obviously incorrect. Every disk used today is divided into
>>> blocks. So that is what a file on a disk is, in the end. And that is not
>>> the same as a string of bytes. The string of bytes abstraction is
>>> implemented on top of this.
>
>> Er, not a very convincing argument. In that vein, every magnetic media
>> disk used today is a string of flux transitions. The bytes and blocks
>> abstraction are implemented on top of this.
>
> Blocks are real on floppy disks, even today. (Well, they might not be
> so easy to find.) I suspect, though, that on the usual hard disk these
> days, that blocks might be mostly virtual.

No. They are still blocks on the spinning rust. SSD is a different
story. But that's all hidden inside the electronics of the drive. The
exposed interface to the rest of the machine is still talking blocks.

> Traditionally, the important part of disk I/O is the write splice, where
> one starts and stops writing a block. The controller/drive has to
> start writing just after the appropriate block header, and stop within
> the gap after the block. But as internal disk buffers got bigger, it is
> now possible for a whole disk track to go into the buffer. Though
> last I knew, disks knew how to start reading in the middle of a track,
> such that it could supply blocks to the system before reading the
> whole track.

Of course. And while disks might have large caches, they still operate
on blocks, and will not rewrite blocks just because they happen to be on
the same track as some other block which is actually supposed to be
written out. And they will not read the whole track in just because they
write a block. That would be pretty bad for performance. But the disk do
try to guess what you might want to read, and when idle, it will such
more data in. Same track is a good start.

> Some earlier drives are likely still running, though.

All kind of drives are still running.

> Note that the rotational speed of disks hasn't changed much over
> about 50 years, and rotational latency is a big part of disk reading.

It has, but not as much as most other parts of computers. And seek times
have improved more than latency, but still not much compared to anything
else.

An RP06 from around 1975 or so spun at 3600 RPM.
Nowadays, the most crazy ones are at 18000 RPM. So that's about a x5
increase in close to 50 years. Rotational latency is definitely a part
of the read times, but seek times used to be the dominant part.

On the RP06, average latency is 8.33ms, while average seek time is
28.5ms. So more than 2/3 of the time is seek time.

On modern drives spinning at slow speeds, latency is the majority of the
time, while on the fast spinning disks, seek and latency are about
equal. Which is why faster spinning disks really gave a boost in
performance.

With SSD you get rid of both, though. :-)

Johnny

Small caveat, I might have reverse character and block device (I tend to
do that sometimes...)

Block - running through the Unix blocking/deblocking, giving you a
stream of bytes.

Character - the basic, raw access to the device. Dealing with blocks.

I do find the names confusing, because I tend to think that character
would be the one that gives a stream of bytes, but it's not...

On 2022-04-12 10:30, gah4 wrote:
> On Monday, April 11, 2022 at 11:42:00 PM UTC-7, Johnny Billquist wrote:
>
> (snip, I wrote)
>>> Disk files on Unix-like systems and DOS/Windows are just a string of bytes.
>>> Any block structure is hidden by the OS disk cache.
>
>> Well, it's not hidden by the OS disk cache in Unix. It's hidden by the
>> device driver framework. That's where the block and character devices is
>> about.
>
> If you do a read() system call on a disk file, it either fills the buffer or
> writes the bytes left in the file. There used to be a rule that you should
> never use the block disk device. That restriction might be gone, but I
> am not sure what happens if you do use it. When I do write raw disk
> devices, I use the character device.

If you do a read on the raw disk, you'll be getting the blocks. You can
only start your operation at a block boundary. Depending on the
hardware, you might be able to not read/write a full block, though. But
in that case, the rest will be padded by something, and not left untouched.

Almost no program would/should ever need to do this, but it works fine.
And obviously, programs like disklabel/mkfs/newfs/fsck and the like
needs to access the disks this way.

The block device is in a way inadvisable to use because the data will be
sitting in OS buffers until sync. And if you just reboot, that data
might be lost then. Remember to sync three times. :-)

So tools that directly want to manipulate the file system are not so
great to use the block device for, since the data is not necessarily on
disk after your write. Also, if it is a mounted file system, Unix copies
and caches data, which aren't synced to your block access. Doubly bad if
you try to manipulated a mounted file system, because that will be
overwritten again by the OS syncing back it's cached data.

So it's not a real restriction to not use the block device when writing
to a disk, but it just creates extra headaches and potential surprises.
But if you want to treat the whole disk as a stream of bytes, you have
to go this way.

>>> On the other hand, tapes on Unix, and I believe DOS/Windows do have a block
>>> structure. In some cases, it is necessary to preserve that in order to
>>> properly read them. There are virtual tape formats that convert a tape of
>>> blocks into a stream with block marks included, and others to reverse it.
>
>> Actually, in Unix, tapes are the same story as disks. However, no sane
>> person ever cared to use the character device for tapes, since (as you
>> observe), with tapes there are additional reasons why you want to know,
>> and preserve block information. The character device hides this from you.
>
> All the Unix tape work I ever did was with the character device.
> Maybe 20 years ago, we did it with tar, where you tell tar the blocking
> factor that you want, and it writes blocks of that size to tape.

So I swapped character and block then. Yes, you use the character device
to get the raw access to the tape. And you want that. But there is also
the block device for tapes, where you just treat a tape like a stream of
bytes. I bet you never used it. Almost noone have, because you don't
actually want that.
What happens there is that Unix internally blocks this up to 1024 byte
blocks that it reads/writes to the tape for you. Just like with a
disk... No indication about block size. No handling of tape marks. It's
all hidden away from you.

> The Unix read() system call on a tape character device returns one tape
> block, and the length of that block. On 9-track reel tape drives that I know,
> you can write any block length you want, with the drive writing the block,
> and an inter-block gap to the tape. Some other tape systems only allow
> for fixed sized blocks.

Right. When you use the character device. Now try the block device.
:evil grin:.

> More recently, I was working with Ultrium (LTO) drives, which have two
> modes. In one mode, the drive writes fixed length (usually 512 byte)
> blocks, the other looks more like 9-track drives. Though in the case
> of LTO all the blocking is virtual. Having the drive in the wrong mode
> confuses programs like tar.

Yeah... That would also mean you could have two layers blocking your
data, if you aren't careful. Quite a mess.

>> For networking, it's all carried by IP datagrams in the end, which are
>> blocks. TCP then implements a stream of bytes abstraction on top of that.
>
> Yes, but TCP won't tell you were the boundaries were before the data
> went into the TCP stream, or where the IP boundaries were.

True. And when I read a file from a disk, the system won't tell me about
the disk block boundaries either. But they do exist. And if I use the
block driver to a tape, I won't know about tape block boundaries either...

Also - I think Linux for example, got rid of the block/character
distinction on devices, and don't really match Unix here. Traditionally,
all disks and tapes had both a block and a character device driver to
access it.

Here is a nice quote from mtio(4) on 2.11BSD:

"
A standard tape consists of a series of 1024 byte records
terminated by an end-of-file. To the extent possible, the
system makes it possible, if inefficient, to treat the tape
like any other file. Seeks have their usual meaning and it
is possible to read or write a byte at a time. Writing in
very small units is inadvisable, however, because it uses
most of the tape in record gaps.

The mt files discussed above are useful when it is desired
to access the tape in a way compatible with ordinary files.
When foreign tapes are to be dealt with, and especially when
long records are to be read or written, the `raw' interface
is appropriate. The associated files are named rmt0, ...,
rmt23, but the same minor-device considerations as for the
regular files still apply. A number of other ioctl opera-
tions are available on raw magnetic tape.
"

Johnny

In article <t33r9h$pr$1@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>On 2022-04-11, VAXman- @SendSpamHere.ORG <VAXman-@SendSpamHere.ORG> wrote:
>> In article <t31ose$pr0$1@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>>
>>>Ok, Brian, you win. I'll be pedantic if you wish. :-)
>>>
>>>Once you have code you control running in one of the hardware inner modes,
>>>you can get to the others without any additional privileges required on
>>>the part of the account doing it.
>>
>> NOT TRUE. Stop confusing $CMKRNL from EXEC mode with all others. You can
>> NOT get to EXEC from SUPERVISOR mode. Granted, you found an exploit with an
>> installed image but that was corrected. There's no $CMEXEC jump from SUPER-
>> VISOR mode without privileges vis-a-vis $CMKRNL from EXEC mode.
>>
>
>You are contradicting yourself with the above statements Brian.
>First you say it's not possible, then you say it's possible if the
>supervisor mode code has access to the privileges of the current image.

IT IS NOT THAT SUPERVISOR MODE GRANTED YOU ANY SPECIAL MOVEMENT TO AN INNER
MODE! You used an image installed with privileges. The gang that found the
SMG$ bug employed an image installed with privileges FROM USER MODE. Bugs
occur in software save, of course, yours -- assuming you can write software
or do you just spend your day littering c.o.v? -- because you are perfect in
every way and noone can question your assertions and aspersions.

>As you have been told multiple times Brian, the only fix was to fix
>the buffer overflow that allowed me to get code running within the
>context of DCL itself. There was nothing fixed to reduce what you can
>do once you are in supervisor mode.

You refuse to see reality. SUPERVISOR mode did NOT grant you access to an
inner mode. My DCL Debugger runs in SUPERVISOR mode. Oh, how I'd wished
that your rose-colored world existed but it does not. I had to go out of
my way to get to inner mode from SUPERVISOR mode to perform certain things
in NON-PRIVILEGED processes debugging DCL.

>If someone finds another way back into supervisor mode, then supervisor
>mode is still as dangerous as it always was.

Find a way into SUPERVISOR mode? It's simple.

>For anyone else wondering why supervisor mode is so dangerous, it's
>because code running in supervisor mode has access to the privileges
>of the current image.

So does USER MODE. ;)

>You are really only limited by your knowledge and imagination with what
>you can do with that. There are two ways I know of to make use of that:
>
>1) The CTRL-Y attack which was part of my exploit.
>
>2) You can activate a privileged image from supervisor mode and then
>use its privileges. You don't have to take my word for this one as
>the image activation sequence is very well documented in the Alpha I&DS
>manual.
>
>If you read the image activation checklist in the Alpha I&DS, you will see
>that the image activator enables the image's privileges in the current
>process and _then_ returns control back to DCL with those elevated
>privileges in place.
>
>So yes, if you have code that you control running in supervisor mode,
>then you can still use it to get into executive or kernel mode.

OK. Write some SUPERVISOR mode code but don't invoke $IMGACT/$IMGFIX to
activate a privileged installed image. Please tell me how you get into
any inner modes? Really, if your way is better than mine, I might redo
my DCL Debugger where it needs inner mode. Betcha can't!

Actually, I don't expect you to do the above as I've requested it many
times in the past and you OBVIOUSLY can't do it. Just keep that tirade
against VMS going though. Oh, if only CJL were still with us.

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

On 2022-04-12, VAXman- @SendSpamHere.ORG <VAXman-@SendSpamHere.ORG> wrote:
> In article <t33r9h$pr$1@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>On 2022-04-11, VAXman- @SendSpamHere.ORG <VAXman-@SendSpamHere.ORG> wrote:
>>> In article <t31ose$pr0$1@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>>>
>>>>Ok, Brian, you win. I'll be pedantic if you wish. :-)
>>>>
>>>>Once you have code you control running in one of the hardware inner modes,
>>>>you can get to the others without any additional privileges required on
>>>>the part of the account doing it.
>>>
>>> NOT TRUE. Stop confusing $CMKRNL from EXEC mode with all others. You can
>>> NOT get to EXEC from SUPERVISOR mode. Granted, you found an exploit with an
>>> installed image but that was corrected. There's no $CMEXEC jump from SUPER-
>>> VISOR mode without privileges vis-a-vis $CMKRNL from EXEC mode.
>>>
>>
>>You are contradicting yourself with the above statements Brian.
>>First you say it's not possible, then you say it's possible if the
>>supervisor mode code has access to the privileges of the current image.
>
> IT IS NOT THAT SUPERVISOR MODE GRANTED YOU ANY SPECIAL MOVEMENT TO AN INNER
> MODE! You used an image installed with privileges. The gang that found the
> SMG$ bug employed an image installed with privileges FROM USER MODE. Bugs
> occur in software save, of course, yours -- assuming you can write software
> or do you just spend your day littering c.o.v? -- because you are perfect in
> every way and noone can question your assertions and aspersions.
>

In a way, it did. The image activator behaves differently when invoked
in supervisor mode compared to when invoked in user mode.

The key question is this: Can a non-privileged user who gets code they
control running in supervisor mode come up with a way to switch to
from supervisor mode to executive mode or kernel mode ?

The answer to that question is yes.

Which means that my original statement about VMS only having a single
inner mode when looked at from the viewpoint of security is also correct.

Simon.

PS: BTW, I don't assume that I am perfect when I write code. That's why
I like languages that help me find errors early on.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On Tue, 12 Apr 2022 15:10:52 +0200, Johnny Billquist wrote:

> Small caveat, I might have reverse character and block device (I tend to
> do that sometimes...)
>
> Block - running through the Unix blocking/deblocking, giving you a
> stream of bytes.
>
> Character - the basic, raw access to the device. Dealing with blocks.
>
>
> I do find the names confusing, because I tend to think that character
> would be the one that gives a stream of bytes, but it's not...

Just use FreeBSD! There is no distinction between devices, and hadn't
been since 5.0.

All are 'character' devices using a unified buffering scheme.

--
My posts are my copyright and if @diy_forums or Home Owners' Hub
wish to copy them they can pay me £1 a message.
Use the BIG mirror service in the UK: http://www.mirrorservice.org
*lightning surge protection* - a w_tom conductor

On 4/12/2022 1:34 PM, Simon Clubley wrote:

> The key question is this: Can a non-privileged user who gets code they
> control running in supervisor mode come up with a way to switch to
> from supervisor mode to executive mode or kernel mode ?

No, unless, there is some bug, and any bugs in any code pretty much calls off
any talk of security.

Yes Simon, you found a bug, and it has now been fixed. Can you still use the
same exploit?

Unless you find another bug, then a non-prived user cannot gain privs, unless
they are granted to that user or process.

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

On 2022-04-12, Dave Froble <davef@tsoft-inc.com> wrote:
> On 4/12/2022 1:34 PM, Simon Clubley wrote:
>
>> The key question is this: Can a non-privileged user who gets code they
>> control running in supervisor mode come up with a way to switch to
>> from supervisor mode to executive mode or kernel mode ?
>
> No, unless, there is some bug, and any bugs in any code pretty much calls off
> any talk of security.
>

Actually, yes you can. If you don't want to mess around with trying to
hook your supervisor mode code into DCL in a way that allows you do
run it while a privileged image is active, you can simply activate a
privileged image while in supervisor mode and then use the privileges
of the image.

If that image has CMEXEC or CMKRNL privilege, you can use them to get
yourself into executive or kernel mode.

It should be considered a bug IMHO, but that's how VMS works.

In fairness, that was probably considered acceptable in the isolated
systems of the 1970s. Today, not so much.

> Yes Simon, you found a bug, and it has now been fixed. Can you still use the
> same exploit?
>
> Unless you find another bug, then a non-prived user cannot gain privs, unless
> they are granted to that user or process.
>

That isn't what this is about.

This discussion started because I am of the opinion, that from
a security point of view, VMS is just another 2-mode operating
system with its single inner mode split across 3 hardware modes.

That means, if you have code running in supervisor mode, that code
can get access to executive or kernel mode without any additional
privileges required on the logged in account itself.

If, OTOH, supervisor mode, never, ever, saw the privileges of the
images it activates, then that would turn VMS into a 3-mode
operating system.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 4/12/2022 6:24 PM, Simon Clubley wrote:
> On 2022-04-12, Dave Froble <davef@tsoft-inc.com> wrote:
>> On 4/12/2022 1:34 PM, Simon Clubley wrote:
>>
>>> The key question is this: Can a non-privileged user who gets code they
>>> control running in supervisor mode come up with a way to switch to
>>> from supervisor mode to executive mode or kernel mode ?
>>
>> No, unless, there is some bug, and any bugs in any code pretty much calls off
>> any talk of security.
>>
>
> Actually, yes you can. If you don't want to mess around with trying to
> hook your supervisor mode code into DCL in a way that allows you do
> run it while a privileged image is active, you can simply activate a
> privileged image while in supervisor mode and then use the privileges
> of the image.

If you can interrupt a priv mode installed image and retain the privs, then that
is a bug.

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

On 2022-04-12 21:09:18 +0000, Dave Froble said:

> On 4/12/2022 1:34 PM, Simon Clubley wrote:
>
>> The key question is this: Can a non-privileged user who gets code they
>> control running in supervisor mode come up with a way to switch to from
>> supervisor mode to executive mode or kernel mode ?
>
> No, unless, there is some bug, and any bugs in any code pretty much
> calls off any talk of security.
>
> Yes Simon, you found a bug, and it has now been fixed. Can you still
> use the same exploit?
>
> Unless you find another bug, then a non-prived user cannot gain privs,
> unless they are granted to that user or process.

Supervisor mode is a trusted mode.

Absent redesigning how an OpenVMS command interpreter works, obtaining
full privileges from arbitrary supervisor mode code is feasible.

There's no bug here.

I explained how this path worked to an OpenVMS developer some years ago.

Them: 😳

--
Pure Personal Opinion | HoffmanLabs LLC

In article <t34d6c$m3a$1@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>On 2022-04-12, VAXman- @SendSpamHere.ORG <VAXman-@SendSpamHere.ORG> wrote:
>> In article <t33r9h$pr$1@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>>On 2022-04-11, VAXman- @SendSpamHere.ORG <VAXman-@SendSpamHere.ORG> wrote:
>>>> In article <t31ose$pr0$1@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>>>>
>>>>>Ok, Brian, you win. I'll be pedantic if you wish. :-)
>>>>>
>>>>>Once you have code you control running in one of the hardware inner modes,
>>>>>you can get to the others without any additional privileges required on
>>>>>the part of the account doing it.
>>>>
>>>> NOT TRUE. Stop confusing $CMKRNL from EXEC mode with all others. You can
>>>> NOT get to EXEC from SUPERVISOR mode. Granted, you found an exploit with an
>>>> installed image but that was corrected. There's no $CMEXEC jump from SUPER-
>>>> VISOR mode without privileges vis-a-vis $CMKRNL from EXEC mode.
>>>>
>>>
>>>You are contradicting yourself with the above statements Brian.
>>>First you say it's not possible, then you say it's possible if the
>>>supervisor mode code has access to the privileges of the current image.
>>
>> IT IS NOT THAT SUPERVISOR MODE GRANTED YOU ANY SPECIAL MOVEMENT TO AN INNER
>> MODE! You used an image installed with privileges. The gang that found the
>> SMG$ bug employed an image installed with privileges FROM USER MODE. Bugs
>> occur in software save, of course, yours -- assuming you can write software
>> or do you just spend your day littering c.o.v? -- because you are perfect in
>> every way and noone can question your assertions and aspersions.
>>
>
>In a way, it did. The image activator behaves differently when invoked
>in supervisor mode compared to when invoked in user mode.

It does not. Explain what you believe is different. You make these stupid
statements but never explain them.

>The key question is this: Can a non-privileged user who gets code they
>control running in supervisor mode come up with a way to switch to
>from supervisor mode to executive mode or kernel mode ?
>
>The answer to that question is yes.

By simple virtue of being in SUPERVISOR more? No. If you'd care to explain
otherwise, I'm listening.

>Which means that my original statement about VMS only having a single
>inner mode when looked at from the viewpoint of security is also correct.

STFU! Put your money/pride where your mouth is and show me/us.

>Simon.
>
>PS: BTW, I don't assume that I am perfect when I write code. That's why
>I like languages that help me find errors early on.

LOL

I'll be away for a week in Sarasota. Take your time and I'll see your lack
of REAL evidence in a week.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

In article <t34u7f$vlv$1@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>On 2022-04-12, Dave Froble <davef@tsoft-inc.com> wrote:
>> On 4/12/2022 1:34 PM, Simon Clubley wrote:
>>
>>> The key question is this: Can a non-privileged user who gets code they
>>> control running in supervisor mode come up with a way to switch to
>>> from supervisor mode to executive mode or kernel mode ?
>>
>> No, unless, there is some bug, and any bugs in any code pretty much calls off
>> any talk of security.
>>
>
>Actually, yes you can. If you don't want to mess around with trying to
>hook your supervisor mode code into DCL in a way that allows you do
>run it while a privileged image is active, you can simply activate a
>privileged image while in supervisor mode and then use the privileges
>of the image.
>
>If that image has CMEXEC or CMKRNL privilege, you can use them to get
>yourself into executive or kernel mode.

Ah, you can't distinguish privileged installed images from inner mode
access but you can lecture us that there's no difference. Yeah, uh, I
get it now... not.

>It should be considered a bug IMHO, but that's how VMS works.
>
>In fairness, that was probably considered acceptable in the isolated
>systems of the 1970s. Today, not so much.
>
>> Yes Simon, you found a bug, and it has now been fixed. Can you still use the
>> same exploit?
>>
>> Unless you find another bug, then a non-prived user cannot gain privs, unless
>> they are granted to that user or process.
>>
>
>That isn't what this is about.
>
>This discussion started because I am of the opinion, that from
>a security point of view, VMS is just another 2-mode operating
>system with its single inner mode split across 3 hardware modes.

Fuck opinions! Opinions are like assholes and yours stinks. Show me a real
world working proof! ... you can't.

>That means, if you have code running in supervisor mode, that code
>can get access to executive or kernel mode without any additional
>privileges required on the logged in account itself.

I have asked repeatedly. PROVE IT or shutup already. Code it and I will
concede. C.O.V. USED to have people that would provide code to prove or
disprove that which they had stated. Seeing as how nobody really knowns
if you know VMS or not, I'd expect you'd follow suit. You talk the talk
but you can not walk the walk.

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

In article <t354r6$eth$1@dont-email.me>, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> writes:
>On 2022-04-12 21:09:18 +0000, Dave Froble said:
>
>> On 4/12/2022 1:34 PM, Simon Clubley wrote:
>>
>>> The key question is this: Can a non-privileged user who gets code they
>>> control running in supervisor mode come up with a way to switch to from
>>> supervisor mode to executive mode or kernel mode ?
>>
>> No, unless, there is some bug, and any bugs in any code pretty much
>> calls off any talk of security.
>>
>> Yes Simon, you found a bug, and it has now been fixed. Can you still
>> use the same exploit?
>>
>> Unless you find another bug, then a non-prived user cannot gain privs,
>> unless they are granted to that user or process.
>
>Supervisor mode is a trusted mode.
>
>Absent redesigning how an OpenVMS command interpreter works, obtaining
>full privileges from arbitrary supervisor mode code is feasible.
>
>There's no bug here.
>
>I explained how this path worked to an OpenVMS developer some years ago.
>
>Them: 😳

Simply from the virtue of being SUPERVISOR? If that were true, then what of
USER mode?

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

On 2022-04-12 14:33, Simon Clubley wrote:
> On 2022-04-12, gah4 <gah4@u.washington.edu> wrote:
>> On Monday, April 11, 2022 at 11:42:00 PM UTC-7, Johnny Billquist wrote:
>>
>>> For networking, it's all carried by IP datagrams in the end, which are
>>> blocks. TCP then implements a stream of bytes abstraction on top of that.
>>
>> Yes, but TCP won't tell you were the boundaries were before the data
>> went into the TCP stream, or where the IP boundaries were.
>
> I wonder if there are any programmers still around that try to
> treat TCP as if it was record based anyway. :-)
>
> I know that in the old days, you sometimes came across reports of
> people that assumed one TCP write in a program turned into exactly
> one read in the receiving program...

Lots of people still believe that. I had to clarify this to a colleague
only the other day.

Johnny

On 4/13/2022 10:08 AM, Johnny Billquist wrote:
> On 2022-04-12 14:33, Simon Clubley wrote:
>> On 2022-04-12, gah4 <gah4@u.washington.edu> wrote:
>>> On Monday, April 11, 2022 at 11:42:00 PM UTC-7, Johnny Billquist wrote:
>>>
>>>> For networking, it's all carried by IP datagrams in the end, which are
>>>> blocks. TCP then implements a stream of bytes abstraction on top of
>>>> that.
>>>
>>> Yes, but TCP won't tell you were the boundaries were before the data
>>> went into the TCP stream, or where the IP boundaries were.
>>
>> I wonder if there are any programmers still around that try to
>> treat TCP as if it was record based anyway. :-)
>>
>> I know that in the old days, you sometimes came across reports of
>> people that assumed one TCP write in a program turned into exactly
>> one read in the receiving program...
>
> Lots of people still believe that. I had to clarify this to a colleague
> only the other day.

Happens all the time.

Some technologies makes it easier to avoid. Both Java
and .NET has a stack:

Java BufferedReader & Print Stream / .NET StreamReader & StreamWriter -
handle read & write of lines of text
Java InputStream & OutputStream / .NET Stream - handle read & write of
byte stream
Java Socket / .NET TcpClient - handle open not read & write

The highest level hides the read loop to read all needed.

Arne