Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

SPECIAL pricing on rx2800 i2 untl October 30

888 views
Skip to first unread message

David Turner

unread,
Sep 19, 2017, 6:20:46 AM9/19/17
to
Get a complete licensed rx2800 i2 - for example

HP Integrity rx2800 i2
1 x AH399A 1.6Ghz Quad Core CPU
32GB (2 x 16GB) memory
8 x 300GB 10K SAS 6G Disk
DVD-ROM
AM252A RAID Extender with 512MB Cache
2 Power Supplies
Rack Kit
Power Cords
NEW HP OpenVMS PSL License BOE

Find it here:
https://www.islandco.com/hp-integrity-server/rx2800-i2-server/AH395A

Total $8100 + US/Canads Shipping included.
International Shipping limited to $400 maximum

Warranty 12 months extendable for $900 per year up to 4 yrs

Call or email us

Island Computers. sa...@islandco.com https://www.islandco.com

https://www.islandco.com/hp-integrity-server/rx2800-i2-server/AH395A

Neil Rieck

unread,
Oct 6, 2017, 9:04:20 AM10/6/17
to
We moved our primary OpenVMS business system from an AlphaServer-DS20e to an rx2800-i2 last year and it was the best decision we ever made. Our client community gave us all the credit when, in truth, we deserved none of it.

Neil Rieck
Waterloo, Ontario, Canada.
http://neilrieck.net/docs/openvms_notes_itanium_diary.html

Arne Vajhøj

unread,
Oct 8, 2017, 11:01:37 PM10/8/17
to
On 10/6/2017 9:04 AM, Neil Rieck wrote:
> We moved our primary OpenVMS business system from an
> AlphaServer-DS20e to an rx2800-i2 last year and it was the best
> decision we ever made. Our client community gave us all the credit
> when, in truth, we deserved none of it.

But those systems are from approx. 2001 and 2011 aren't they?

Hardly surprising that 10 years newer systems perform better.

Arne

Neil Rieck

unread,
Oct 11, 2017, 9:24:16 AM10/11/17
to
You are 100% and it is something I've only seen with VMS and OpenVMS applications. They just continue to work, work, work. Believe it or not, there are still companies running VAX/VMS on VAX although most have been convinced to move to emulation (eg. Charon-VAX on DL385 etc.).

I ran into this with my own employer. We built a sound case for moving some applications from ten VAX machines to ten Alpha-Servers but this proposal occurred during the dot-com crisis so was never implemented because no one wanted to write a cheque to fund it. Other systems I worked on did move from VAX to Alpha, then Alpha to Itanium.

Meanwhile, with the passage of time, the 10 systems still running on VAX were an even bigger mystery to the contractors tasked to maintain them. Because of this, the only conservative way forward for the contractors was to move them to VAX emulation. And it worked for a time. Then other software contractors were hired to add web-based reports to that VAX solution. Only after the contractors were hired did they learn that Apache (their preferred web-server) was not available for VAX, and they were unwilling to commit to unknown alternatives like WASD. So they recommended ditching the whole VMS thing for a brand new solution built upon Linux and Oracle, and my employer went for it.

Funny thing #1: they tried to cutover the whole thing in 2015 but the new systems couldn't keep up. So now my employer is supporting two whole systems in parallel while the contractor slowly moves functionality from VMS to Linux. This is still true in October 2017

Funny thing #2: tying to save money, in 2016 my employer prematurely dropped support for the VMS systems starting Jan-1, 2017 (they assumed the Linux/Oracle solution would be working by then). But then in mid-2017 some of the VMS systems running under emulation began experiencing hardware problems (bad drives) but no one knew because no one was doing proactive monitoring of the RAID shleves. Then they lost one system completely and were scrambling to locate off site backups (where being done over a network so could have been located anywhere in the world)

I am writing this to you all because I can prove that moving VMS/OpenVMS applications to newer platforms was a far less expensive alternative. Software continues to be valuable while hardware gets cheaper, cheaper, cheaper.

Bill Gunshannon

unread,
Oct 11, 2017, 10:55:33 AM10/11/17
to
On 10/11/2017 09:24 AM, Neil Rieck wrote:
> You are 100% and it is something I've only seen with VMS and OpenVMS applications. They just continue to work, work, work. Believe it or not, there are still companies running VAX/VMS on VAX although most have been convinced to move to emulation (eg. Charon-VAX on DL385 etc.).
>

Big deal. There are still people running PDP-11's and, yes,
Prime 50 Series. (Pretty sure there are still DEC System10
and System20, too)

Not sure what that really says about any of them.

bill

David Froble

unread,
Oct 11, 2017, 11:21:38 AM10/11/17
to
Neil Rieck wrote:
> You are 100% and it is something I've only seen with VMS and OpenVMS
> applications. They just continue to work, work, work. Believe it or not,
> there are still companies running VAX/VMS on VAX although most have been
> convinced to move to emulation (eg. Charon-VAX on DL385 etc.).
>
> I ran into this with my own employer. We built a sound case for moving some
> applications from ten VAX machines to ten Alpha-Servers but this proposal
> occurred during the dot-com crisis so was never implemented because no one
> wanted to write a cheque to fund it. Other systems I worked on did move from
> VAX to Alpha, then Alpha to Itanium.
>
> Meanwhile, with the passage of time, the 10 systems still running on VAX were
> an even bigger mystery to the contractors tasked to maintain them. Because of
> this, the only conservative way forward for the contractors was to move them
> to VAX emulation. And it worked for a time. Then other software contractors
> were hired to add web-based reports to that VAX solution. Only after the
> contractors were hired did they learn that Apache (their preferred
> web-server) was not available for VAX, and they were unwilling to commit to
> unknown alternatives like WASD. So they recommended ditching the whole VMS
> thing for a brand new solution built upon Linux and Oracle, and my employer
> went for it.
>
> Funny thing #1: they tried to cutover the whole thing in 2015 but the new
> systems couldn't keep up. So now my employer is supporting two whole systems
> in parallel while the contractor slowly moves functionality from VMS to
> Linux. This is still true in October 2017

And, being managers, who will never admit being wrong, they will not drop the
non-performing idea and go back to what still works, huh?

> Funny thing #2: tying to save money, in 2016 my employer prematurely dropped
> support for the VMS systems starting Jan-1, 2017 (they assumed the
> Linux/Oracle solution would be working by then). But then in mid-2017 some of
> the VMS systems running under emulation began experiencing hardware problems
> (bad drives) but no one knew because no one was doing proactive monitoring of
> the RAID shleves. Then they lost one system completely and were scrambling to
> locate off site backups (where being done over a network so could have been
> located anywhere in the world)
>
> I am writing this to you all because I can prove that moving VMS/OpenVMS
> applications to newer platforms was a far less expensive alternative.
> Software continues to be valuable while hardware gets cheaper, cheaper,
> cheaper.

We've done it with software that has it's roots in the 1970s.

David Froble

unread,
Oct 11, 2017, 11:22:15 AM10/11/17
to
That they are still doing the original job for which they were purchased?

Bill Gunshannon

unread,
Oct 11, 2017, 11:44:04 AM10/11/17
to
Well, certainly no doubt about that. That's what has kept the IBM 360
architecture and the Univac 1100 architecture going for all these years
long after people said they should be dead.

bill

Simon Clubley

unread,
Oct 11, 2017, 1:29:35 PM10/11/17
to
On 2017-10-11, David Froble <da...@tsoft-inc.com> wrote:
> Bill Gunshannon wrote:
>> On 10/11/2017 09:24 AM, Neil Rieck wrote:
>>> You are 100% and it is something I've only seen with VMS and OpenVMS
>>> applications. They just continue to work, work, work. Believe it or
>>> not, there are still companies running VAX/VMS on VAX although most
>>> have been convinced to move to emulation (eg. Charon-VAX on DL385 etc.).
>>>

I really hope those people have considered the risks of continuing to
run out of date and insecure versions of VMS when doing that. I also
hope they have taken measures to isolate those systems to protect
against any future vulnerabilities which might be discovered that also
affect VAX/VMS.

>>
>> Big deal. There are still people running PDP-11's and, yes,
>> Prime 50 Series. (Pretty sure there are still DEC System10
>> and System20, too)
>>
>> Not sure what that really says about any of them.
>>
>> bill
>>
>
> That they are still doing the original job for which they were purchased?

No, it says they are able to carry out those tasks but it says nothing
about whether they are still able to carry out those tasks in a secure
manner.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Bill Gunshannon

unread,
Oct 11, 2017, 3:32:45 PM10/11/17
to
On 10/11/2017 01:29 PM, Simon Clubley wrote:
> On 2017-10-11, David Froble <da...@tsoft-inc.com> wrote:
>> Bill Gunshannon wrote:
>>> On 10/11/2017 09:24 AM, Neil Rieck wrote:
>>>> You are 100% and it is something I've only seen with VMS and OpenVMS
>>>> applications. They just continue to work, work, work. Believe it or
>>>> not, there are still companies running VAX/VMS on VAX although most
>>>> have been convinced to move to emulation (eg. Charon-VAX on DL385 etc.).
>>>>
>
> I really hope those people have considered the risks of continuing to
> run out of date and insecure versions of VMS when doing that. I also
> hope they have taken measures to isolate those systems to protect
> against any future vulnerabilities which might be discovered that also
> affect VAX/VMS.
>
>>>
>>> Big deal. There are still people running PDP-11's and, yes,
>>> Prime 50 Series. (Pretty sure there are still DEC System10
>>> and System20, too)
>>>
>>> Not sure what that really says about any of them.
>>>
>>> bill
>>>
>>
>> That they are still doing the original job for which they were purchased?
>
> No, it says they are able to carry out those tasks but it says nothing
> about whether they are still able to carry out those tasks in a secure
> manner.
>

Well, if your still running RSTS on a PDP-11 it's gotta be
pretty secure as there is no way the machine is on the
Internet at all. Might be accessible from the Internet,
but that would be thru a terminal server. :-)

Maybe that's the answer to the recent spate of security breaches.
Let's go back to RSTS and no Internet. :-)

bill

George Cornelius

unread,
Oct 11, 2017, 6:36:12 PM10/11/17
to
In article <f479up...@mid.individual.net>, Bill Gunshannon <bill.gu...@gmail.com> writes:
> On 10/11/2017 01:29 PM, Simon Clubley wrote:
[...]

>> No, it says they are able to carry out those tasks but it says nothing
>> about whether they are still able to carry out those tasks in a secure
>> manner.
>>
>
> Well, if your still running RSTS on a PDP-11 it's gotta be
> pretty secure as there is no way the machine is on the
> Internet at all. Might be accessible from the Internet,
> but that would be thru a terminal server. :-)

You mean Johnny never ported his IP stack to RSTS???

George

Arne Vajhøj

unread,
Oct 11, 2017, 7:20:27 PM10/11/17
to
On 10/11/2017 1:29 PM, Simon Clubley wrote:
> On 2017-10-11, David Froble <da...@tsoft-inc.com> wrote:
>> Bill Gunshannon wrote:
>>> On 10/11/2017 09:24 AM, Neil Rieck wrote:
>>>> You are 100% and it is something I've only seen with VMS and OpenVMS
>>>> applications. They just continue to work, work, work. Believe it or
>>>> not, there are still companies running VAX/VMS on VAX although most
>>>> have been convinced to move to emulation (eg. Charon-VAX on DL385 etc.).
>
> I really hope those people have considered the risks of continuing to
> run out of date and insecure versions of VMS when doing that. I also
> hope they have taken measures to isolate those systems to protect
> against any future vulnerabilities which might be discovered that also
> affect VAX/VMS.

A VMS VAX system connected to the internet exposing a bunch of
services to the internet (HTTP, FTP, SMTP, POP3, Finger etc.)
would be a huge risk.

A VMS VAX system on an internal network without TCP/IP
would still be a security risk, but I would say a minor
one. Malware attacks via DECnet is very rare in this century.
The biggest risk must be an insider attack.

Arne




Johnny Billquist

unread,
Oct 11, 2017, 7:28:48 PM10/11/17
to
On 2017-10-12 00:33, George Cornelius wrote:
> In article <f479up...@mid.individual.net>, Bill Gunshannon <bill.gu...@gmail.com> writes:
>> On 10/11/2017 01:29 PM, Simon Clubley wrote:
> [...]
>
>>> No, it says they are able to carry out those tasks but it says nothing
>>> about whether they are still able to carry out those tasks in a secure
>>> manner.
>>>
>>
>> Well, if your still running RSTS on a PDP-11 it's gotta be
>> pretty secure as there is no way the machine is on the
>> Internet at all. Might be accessible from the Internet,
>> but that would be thru a terminal server. :-)
>
> You mean Johnny never ported his IP stack to RSTS???

Nope. I have not. Might be possible, but would not be trivial. :-)
But I know of another effort to do TCP/IP on RSTS/E, but that guy
stopped after he had UDP running.
I've had one or two inquiries about the possibility of porting it, though.

And then we have Steve Baldwin who wrote a TCP/IP for RT-11 and TSX...

>> Maybe that's the answer to the recent spate of security breaches.
>> Let's go back to RSTS and no Internet. :-)

Well, I would put my head out a bit and say that RSTS/E is not totally
outside of the internet even without a TCP/IP stack. It certainly have
DECnet, and for some purposes and intent, you can sometimes bridge
between DECnet and TCP/IP, so at least partially, RSTS/E can be on the
internet even without a terminal server.

I think RSX is pretty secure on the internet, even with TCP/IP. Maybe
partly just because of obscurity. There are lots and lots of attempts at
attacking the machines, but they all fail miserably, as there is no user
called "root", nor a web interface to the file system which understands
../../../../etc/passwd, or would ever give any meaningful information
even if it did understand the path. Not to mention that when you telnet
to the machine, it don't immediately prompt you for a username. That
last one appears to be a rally big stumbling block for all crackers out
there...

Imagine a system where you can actually have a command prompt, and issue
commands to the CLI while not being logged in...

Johnny

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol

Simon Clubley

unread,
Oct 11, 2017, 8:04:02 PM10/11/17
to
On 2017-10-11, Arne Vajhøj <ar...@vajhoej.dk> wrote:
> On 10/11/2017 1:29 PM, Simon Clubley wrote:
>> I really hope those people have considered the risks of continuing to
>> run out of date and insecure versions of VMS when doing that. I also
>> hope they have taken measures to isolate those systems to protect
>> against any future vulnerabilities which might be discovered that also
>> affect VAX/VMS.
>
> A VMS VAX system connected to the internet exposing a bunch of
> services to the internet (HTTP, FTP, SMTP, POP3, Finger etc.)
> would be a huge risk.
>

They could also be exposed even if they are not connected to the
outside world, but only to the internal network. An insecure
internal network can be just as hostile as the external internet.

> A VMS VAX system on an internal network without TCP/IP
> would still be a security risk, but I would say a minor
> one. Malware attacks via DECnet is very rare in this century.

That isn't the only concern. A person with appropriate knowledge
and with non-privileged access to the command line may also be
able to compromise the system.

> The biggest risk must be an insider attack.
>

And that is exactly why the latter issue is also of concern.

Bill Gunshannon

unread,
Oct 11, 2017, 8:11:44 PM10/11/17
to
On 10/11/2017 06:33 PM, George Cornelius wrote:
> In article <f479up...@mid.individual.net>, Bill Gunshannon <bill.gu...@gmail.com> writes:
>> On 10/11/2017 01:29 PM, Simon Clubley wrote:
> [...]
>
>>> No, it says they are able to carry out those tasks but it says nothing
>>> about whether they are still able to carry out those tasks in a secure
>>> manner.
>>>
>>
>> Well, if your still running RSTS on a PDP-11 it's gotta be
>> pretty secure as there is no way the machine is on the
>> Internet at all. Might be accessible from the Internet,
>> but that would be thru a terminal server. :-)
>
> You mean Johnny never ported his IP stack to RSTS???
>

Sadly, as far as I know, no. If they ever release the source
it might be fun to do it, though. And put a web server on it
like I have on the 6809 sitting next to me now. :-)

bill


Bill Gunshannon

unread,
Oct 11, 2017, 8:13:42 PM10/11/17
to
Wouldn't you consider Berkeley RSH to be that?

bill


Kerry Main

unread,
Oct 11, 2017, 9:45:06 PM10/11/17
to comp.os.vms to email gateway
> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf Of
> Simon Clubley via Info-vax
> Sent: October 11, 2017 8:04 PM
> To: info...@rbnsn.com
> Cc: Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP>
> Subject: Re: [Info-vax] SPECIAL pricing on rx2800 i2 untl October 30
>
> On 2017-10-11, Arne Vajhøj <ar...@vajhoej.dk> wrote:
> > On 10/11/2017 1:29 PM, Simon Clubley wrote:
> >> I really hope those people have considered the risks of continuing
to
> >> run out of date and insecure versions of VMS when doing that. I
also
> >> hope they have taken measures to isolate those systems to protect
> >> against any future vulnerabilities which might be discovered that
also
> >> affect VAX/VMS.
> >
> > A VMS VAX system connected to the internet exposing a bunch of
> > services to the internet (HTTP, FTP, SMTP, POP3, Finger etc.)
> > would be a huge risk.
> >

If using the native stack, this would be true.

Course, outside of the DEFCON stuff, I have never heard on any system
running Finger on a VMS system.

If using Multinet, their latest versions which align with latest
Internet standards are supported on VAX 5.5-2 and later.

Also on Alpha V6.2 and IA64 V8.2 and later.

>
> They could also be exposed even if they are not connected to the
> outside world, but only to the internal network. An insecure
> internal network can be just as hostile as the external internet.
>
> > A VMS VAX system on an internal network without TCP/IP
> > would still be a security risk, but I would say a minor
> > one. Malware attacks via DECnet is very rare in this century.
>
> That isn't the only concern. A person with appropriate knowledge
> and with non-privileged access to the command line may also be
> able to compromise the system.
>
> > The biggest risk must be an insider attack.
> >
>
> And that is exactly why the latter issue is also of concern.
>
> Simon.
>

Increasing security is like increasing the amount of insurance one has.

If you plan to never get sick or be in an accident, then having only
basic insurance is a great way to save $'s.

On the other hand, if you do get into an accident, then you can never
have to much insurance.

If only using DECnet, then one also has to balance this with the risk
someone having the knowledge to hack DECnet. One could easily argue that
if you put 100 hackers in a room, 95 of them will know how to hack
Windows/*nix. Of those 100, maybe 5 might have some experience with
OpenVMS. Of those 5, maybe 1 or 2 persons might have the understanding
to hack DECnet/OpenVMS.

Given this scenario, yes there is always some risk, but the probability
is extremely low. Hence, the added "insurance" costs are hard to
justify.

And that is part of the reason why there are still lots of mission
critical SCADA and other manufacturing process control systems running
OpenVMS/DECnet.


Regards,

Kerry Main
Kerry dot main at starkgaming dot com




Johnny Billquist

unread,
Oct 12, 2017, 3:04:16 AM10/12/17
to
Not sure what rsh you refer to. When you say rsh, I associate it with
the command and protocol to execute command at remote hosts. It does log
you in at the remote node, although not by using a name and password,
but instead by having you be considered a known and trusted peer.

It does not allow you to execute commands in a logged out state. So it
is something completely different to what I'm referring to.

Or are you thinking of something else?

To understand what I mean, try telnet mim.update.uu.se, and then just
type HELP.

Johnny Billquist

unread,
Oct 12, 2017, 3:05:25 AM10/12/17
to
"They"? It's just me. And if you really want to try, just talk to me,
and we'll see if you can carry such a thing through.

Simon Clubley

unread,
Oct 12, 2017, 8:25:48 AM10/12/17
to
On 2017-10-11, Kerry Main <kemain...@gmail.com> wrote:
>
> If using Multinet, their latest versions which align with latest
> Internet standards are supported on VAX 5.5-2 and later.
>

Just because something is standards compliant, it doesn't automatically
mean it is bug free.

>
> If only using DECnet, then one also has to balance this with the risk
> someone having the knowledge to hack DECnet. One could easily argue that
> if you put 100 hackers in a room, 95 of them will know how to hack
> Windows/*nix. Of those 100, maybe 5 might have some experience with
> OpenVMS. Of those 5, maybe 1 or 2 persons might have the understanding
> to hack DECnet/OpenVMS.
>

I noticed you didn't answer the bit about a logged in, but non-privileged
user sat at a command line being able to exploit system vulnerabilities.

> Given this scenario, yes there is always some risk, but the probability
> is extremely low. Hence, the added "insurance" costs are hard to
> justify.
>

Long term, security by obscurity does not work and only gives you
a false sense of security.

It also leaves you very vulnerable to the situation changing rapidly.
For example, if someone sees the "VMS is really secure" stuff on the
VSI website and decides to put that to the test.

Anything found in x86-64/IA64/Alpha could work on VAX as well and your
out of software support VAX now has a vulnerability that you may have
no way to fix. Now what do you do ?

Running a VAX in production is like running Windows XP or an old
Windows Server version in production. If you decide to do that, you
had better have a bulletproof operating environment for that server
so that it doesn't matter how many vulnerabilities are discovered
and become public knowledge.

Bill Gunshannon

unread,
Oct 12, 2017, 8:29:43 AM10/12/17
to
On 10/12/2017 03:05 AM, Johnny Billquist wrote:
> On 2017-10-12 02:11, Bill Gunshannon wrote:
>> On 10/11/2017 06:33 PM, George Cornelius wrote:
>>> In article <f479up...@mid.individual.net>, Bill Gunshannon
>>> <bill.gu...@gmail.com> writes:
>>>> On 10/11/2017 01:29 PM, Simon Clubley wrote:
>>> [...]
>>>
>>>>> No, it says they are able to carry out those tasks but it says nothing
>>>>> about whether they are still able to carry out those tasks in a secure
>>>>> manner.
>>>>>
>>>>
>>>> Well, if your still running RSTS on a PDP-11 it's gotta be
>>>> pretty secure as there is no way the machine is on the
>>>> Internet at all.  Might be accessible from the Internet,
>>>> but that would be thru a terminal server. :-)
>>>
>>> You mean Johnny never ported his IP stack to RSTS???
>>>
>>
>> Sadly, as far as I know, no.  If they ever release the source
>> it might be fun to do it, though.  And put a web server on it
>> like I have on the 6809 sitting next to me now.  :-)
>
> "They"? It's just me. And if you really want to try, just talk to me,
> and we'll see if you can carry such a thing through.
>

No, I meant the source to RSTS. "They" have it but I don't know
if anyone even knows who "they" are or what their plans, if any,
for the PDP-11 OSes is.

bill

Bill Gunshannon

unread,
Oct 12, 2017, 8:33:01 AM10/12/17
to
That is what I was thinking of. I don;t see how any OS could execute
anything in a truly logged out state. There is always user info needed
to execute any program/command and running as any particular user would
seem to imply "logged in" at some level. Maybe not recorded and tracked
(X11 was famous for this) but still "logged in".

bill


Dennis Boone

unread,
Oct 12, 2017, 9:48:32 AM10/12/17
to
> That is what I was thinking of. I don;t see how any OS could execute
> anything in a truly logged out state. There is always user info needed
> to execute any program/command and running as any particular user would
> seem to imply "logged in" at some level. Maybe not recorded and tracked
> (X11 was famous for this) but still "logged in".

Primos accepted several commands while logged-out, too. You certainly
weren't logged in there. All it had was your line number.

De

Bob Koehler

unread,
Oct 12, 2017, 9:51:39 AM10/12/17
to
In article <f495nr...@mid.individual.net>, Bill Gunshannon <bill.gu...@gmail.com> writes:
>
> That is what I was thinking of. I don;t see how any OS could execute
> anything in a truly logged out state. There is always user info needed
> to execute any program/command and running as any particular user would
> seem to imply "logged in" at some level. Maybe not recorded and tracked
> (X11 was famous for this) but still "logged in".

You've never used TOPS-10? You get a different prompt before you log
in, and there are several informational commands you are allowed to use
without logging in.

Chris

unread,
Oct 12, 2017, 10:11:17 AM10/12/17
to
What the posts here all miss is the fact that the vast majority of
exploits depend on getting an executable binary running on the
target, so if it's not X86, it doesn't run. Just how many exploits
currently exist that would run on pdp, vax, alpha or even
itanium ?. It's one of the reasons why I run non x86 servers here,
as they are inherently more secure by default. Not saying it isn't
an issue, but the risk is minimal with correctly configured
systems and firewalling...

Regards,

Chris


Chris

unread,
Oct 12, 2017, 10:19:28 AM10/12/17
to
Well, if you can't trust your staff, you have much bigger
problems and no amount of system security will fix that. The
external threat is by far the biggest problem, especially if
you have internet facing X86 boxes, irrespective of the OS...

Regards,

Chris


Henry Crun

unread,
Oct 12, 2017, 10:45:05 AM10/12/17
to
IIRC RSTS could run SYSTAT before actually logging in.
You could also make additions to some DATA lines in LOGIN.BAS to allow running
other stuff...

Remember "Please say Hello" ?


--
No Micro$oft products were used in the URLs above, or in preparing this message.
Recommended reading: http://www.catb.org/~esr/faqs/smart-questions.html#before
and: http://alpha.mike-r.com/jargon/T/top-post.html

Bill Gunshannon

unread,
Oct 12, 2017, 10:45:57 AM10/12/17
to
But those commands run as someone. Dennis mentioned Primos. I don't
remember ever running commands without loggin in, but then, you had the
console. You didn't log in on it but it was connected to the system as
a user with elevated privileges. (anybody here ever hear about someone
calling in claiming to be a Prime CE and having the operator switch the
console to remote? :-) I am sure any connection that accepts commands
is technically logged in as some default user and not just running in
open space. The question then becomes who is that user and what level
of privileges does it have.

bill

Bill Gunshannon

unread,
Oct 12, 2017, 10:50:58 AM10/12/17
to
Well, I think the VAX and PDP might be fairly safe, but I have dealt
with numerous exploits that were PHP based so any machine running PHP
is exploitable. I have even seen PHP telnetd programs that could be
loaded on a machine using the webserver and then run giving the attacker
his first foothold.

> It's one of the reasons why I run non x86 servers here,
> as they are inherently more secure by default. Not saying it isn't
> an issue, but the risk is minimal with correctly configured
> systems and firewalling...

A very naive viewpoint. Just because the majority of attacks today are
targeted at Intel based boxes does not mean the others are somehow more
secure.

bill


Bill Gunshannon

unread,
Oct 12, 2017, 10:56:06 AM10/12/17
to
Like others, just because you didn't log in doesn't mean no user is
associated with the command. On most of these machines, until the
login process is run the system is functioning as the SYSTEM User. A
security hole in itself but so it goes. (Anybody remember how you
break into a RSTS machine you don;t have the password for? :-)
VMS runs a whole bunch of commands while booting before the first login
prompt is presented. Do you consider this as "running commands without
logging in"? What user is running these commands?

bill


Paul Sture

unread,
Oct 12, 2017, 11:07:12 AM10/12/17
to
But, a bit like running sshd on a non-standard port, you cut out the
script kiddies (and in that case the size of your log files) in one fell
swoop.

You won't defeat the determined and skilled bad guys, but you will
make it more difficult for them to hide in the noise generated by the
others. Anything which increases your odds of detecting an attack
is a good thing, no?

--
Everybody has a testing environment. Some people are lucky enough to
have a totally separate environment to run production in.


Henry Crun

unread,
Oct 12, 2017, 11:30:05 AM10/12/17
to
Well the login process on VMS is created but not through LOGINOUT,
in fact you can disuser the SYSTEM user and VMS will still start -- of course it
will fail a lot of stuff later in the process! (at any rate that used to work on
older versions; haven't tried that in several decades)

And on RSTS running logged out commands there was no user logged in that you
could see. Definitely not SYSTEM, as the equivalent was [1,2]

Bill Gunshannon

unread,
Oct 12, 2017, 12:29:22 PM10/12/17
to
That you could see! That's my point. Just because it skips all the
logging phases doesn't mean there isn't a user "logged in" to run the
commands. The reason I asked about breaking into RSTS was the standard
way was to interrupt the boot process and run $MONEY which will show you
all the registered users and their passwords. Obviously the user at
that point is privileged but no one has actually logged in yet.

I think this is rapidly becoming a matter of semantics. If I run a
cron job at 3:00 AM when I am fast asleep and no one is in the office
or computer room is that considered running in a non-logged in state?

If a system is running and further commands can be run then a user is
"logged in" it may not have been done explicitly, but nothing is done
on any computer I have ever worked with that did not involve a user
even if it was only the operator.

bill

David Froble

unread,
Oct 12, 2017, 1:05:59 PM10/12/17
to
Well, define "logged in".

There needs to be "something", such as a process, job, and such.

I seem to recall something in the past that allowed such a thing. Can't
remember what. Damn senility.

There was the multi-terminal stuff in RSTS, but, that was an existing job
controlling multiple terminals.

Simon Clubley

unread,
Oct 12, 2017, 1:27:02 PM10/12/17
to
On 2017-10-12, Chris <xxx.sys...@gfsys.co.uk> wrote:
>
> Well, if you can't trust your staff, you have much bigger
> problems and no amount of system security will fix that. The
> external threat is by far the biggest problem, especially if
> you have internet facing X86 boxes, irrespective of the OS...
>

Actually, while outside threats tend to have a high profile, inside
threats are generally considered more dangerous in some areas.

Here is one article I have just found with Google:

https://www.tripwire.com/state-of-security/security-data-protection/insider-threats-main-security-threat-2017/

Simon Clubley

unread,
Oct 12, 2017, 1:43:39 PM10/12/17
to
On 2017-10-12, Bill Gunshannon <bill.gu...@gmail.com> wrote:
> On 10/12/2017 10:11 AM, Chris wrote:
>>
>> What the posts here all miss is the fact that the vast majority of
>> exploits depend on getting an executable binary running on the
>> target, so if it's not X86, it doesn't run. Just how many exploits
>> currently exist that would run on pdp, vax, alpha or even
>> itanium ?.
>

That's only true when you are targeting Linux and Windows.

If you are targeting VMS, you write shellcode for the architectures
that VMS runs on.

You may also find that if you discover a vulnerability in Alpha VMS
then the same vulnerability might also work on VAX VMS if a VAX
version of the shellcode is produced.

When VMS on x86-64 becomes available, then you are likely to find
a good number of people probing it, especially given the security
related language on the VSI website. You may discover that those
same flaws may also work on earlier VMS architectures.

> Well, I think the VAX and PDP might be fairly safe, but I have dealt
> with numerous exploits that were PHP based so any machine running PHP
> is exploitable.
>

VMS on VAX is not safe.

Paul Sture

unread,
Oct 12, 2017, 1:45:48 PM10/12/17
to
On 2017-10-12, Bill Gunshannon <bill.gu...@gmail.com> wrote:
I have two sets of cron jobs on my *nix-based systems. One set runs as
root (typically system maintenance stuff like rotating logs), and the
other set runs as individual users, which have the process rights of
those users, create files under the ownership of that user, etc.

User 'nobody' also features somewhere in the scheme, dependant on the
flavour of *nix and applications you are using.

<https://unix.stackexchange.com/questions/186568/what-is-nobody-user-and-group#186581>

"The nobody user is a pseudo user in many Unixes and Linux
distributions. According to the Linux Standard Base, the nobody user
and its group are an optional mnemonic user and group. That user is
meant to represent the user with the least permissions on the
system. In the best case that user and its group are not assigned to
any file or directory (as owner). This user is in his corresponding
group that is (according to LSB) also called "nobody" and in no
other group.

In earlier Unixes and Linux distributions daemon (for example a
webserver) were called under the nobody user. If a malicious user
gained control over such a daemon, the damage he can perform is
limited to what the daemon can. But the problem is, when there are
multiple daemons running with the nobody user, this has no sense
anymore. That's why today such daemons have their own user.

The nobody user should have no shell assigned to it. Different
distributions handle that in different ways: some refer to
/sbin/nologin that prints a message; some refer to /bin/false that
simply exits with 1 (false); or some just disable the user in
/etc/shadow.

Simon Clubley

unread,
Oct 12, 2017, 1:47:56 PM10/12/17
to
On 2017-10-12, David Froble <da...@tsoft-inc.com> wrote:
>
> There needs to be "something", such as a process, job, and such.
>

For some special cases, that something could always be in kernel mode,
outside of process context. For example, you don't create a process
everytime you send a PING reply...

Stephen Hoffman

unread,
Oct 12, 2017, 1:57:24 PM10/12/17
to
On 2017-10-12 12:25:45 +0000, Simon Clubley said:

> Just because something is standards compliant, it doesn't automatically
> mean it is bug free.

“It is difficult to get a man to understand something, when his salary
depends on his not understanding it.”

Times change, threats change, staffing changes, costs and benefits and
methods of attacks change, which means that platforms too have to
change.

Platforms more than a few years old and under-maintained will never be
secure, and management is betting that the combination of the cost of
remediation and/or the cost of the golden parachutes for themselves
and/or the cost of insurance will be less likely or less costly than
keeping the environments current; they're making a bet that the
organization won't end up as the next breach or suddenly encrypted sans
key, or that they'll be clear by the time that any breach happens.
Not that the golden parachutes and the early retirements that arise
after breaches serve as anything but encouragement to continue with
some of these decisions. Not that network isolation is a viable
strategy, either.




--
Pure Personal Opinion | HoffmanLabs LLC

Bill Gunshannon

unread,
Oct 12, 2017, 2:46:28 PM10/12/17
to
Don't assume the name "nobody" has any significance at all. It
is a regular user who the admin is supposed to keep limited but
it is a regular user just the same. Like root, it is not the
name that provides significance to the system but the UID. The
name could be anything.

bill

Bill Gunshannon

unread,
Oct 12, 2017, 2:48:26 PM10/12/17
to
My point exactly.

>
> There needs to be "something", such as a process, job, and such.
>
> I seem to recall something in the past that allowed such a thing.  Can't
> remember what.  Damn senility.
>
> There was the multi-terminal stuff in RSTS, but, that was an existing
> job controlling multiple terminals.

No process has run on any OS I have ever worked on without
someone owning it.

bill

Bill Gunshannon

unread,
Oct 12, 2017, 2:50:36 PM10/12/17
to
On 10/12/2017 01:47 PM, Simon Clubley wrote:
> On 2017-10-12, David Froble <da...@tsoft-inc.com> wrote:
>>
>> There needs to be "something", such as a process, job, and such.
>>
>
> For some special cases, that something could always be in kernel mode,
> outside of process context. For example, you don't create a process
> everytime you send a PING reply...
>
Who owns the daemon returning the PING reply? Even kernel
processes on Unix belong to someone. I am sure VMS is the
same.

bill


Simon Clubley

unread,
Oct 12, 2017, 4:09:50 PM10/12/17
to
On 2017-10-12, Bill Gunshannon <bill.gu...@gmail.com> wrote:
Unless something has changed, it's all done inside the kernel by
cooperating drivers buried inside the kernel. As far as I am aware,
there is absolutely no process context involved (not even an ACP)
when sending a PING reply.

There is a TCPIP$INETACP process but that is basically the UCX
version of inetd.

Chris

unread,
Oct 12, 2017, 5:38:12 PM10/12/17
to
On 10/12/17 17:27, Simon Clubley wrote:
> On 2017-10-12, Chris<xxx.sys...@gfsys.co.uk> wrote:
>>
>> Well, if you can't trust your staff, you have much bigger
>> problems and no amount of system security will fix that. The
>> external threat is by far the biggest problem, especially if
>> you have internet facing X86 boxes, irrespective of the OS...
>>
>
> Actually, while outside threats tend to have a high profile, inside
> threats are generally considered more dangerous in some areas.
>
> Here is one article I have just found with Google:
>
> https://www.tripwire.com/state-of-security/security-data-protection/insider-threats-main-security-threat-2017/
>
> Simon.
>

It probably is more dangerous, but security is not just about
machines and software, but a big picture attitude within
organisations. They need to develop and maintain internal
cultures and processes that are security focused. Continually
developed and updated as technology and the social environment
changes. It's not something that you can just fit and forget,
though i'm sure many organisations do just that. The tech is
there to make systems secure, but all edges implementation is
often not, judging by he number of naive sounding attacks that
cause major chaos.

For example, it shouldn't be possible for phishing attack
emails to get anywhere near internal networks, or for content
of emails to be executable. You would think that would be easy
to fix but is it ?...

Regards,

Chris

Chris

unread,
Oct 12, 2017, 5:55:02 PM10/12/17
to
On 10/12/17 20:09, Simon Clubley wrote:
> On 2017-10-12, Bill Gunshannon<bill.gu...@gmail.com> wrote:
>> On 10/12/2017 01:47 PM, Simon Clubley wrote:
>>> On 2017-10-12, David Froble<da...@tsoft-inc.com> wrote:
>>>>
>>>> There needs to be "something", such as a process, job, and such.
>>>>
>>>
>>> For some special cases, that something could always be in kernel mode,
>>> outside of process context. For example, you don't create a process
>>> everytime you send a PING reply...
>>>
>> Who owns the daemon returning the PING reply? Even kernel
>> processes on Unix belong to someone. I am sure VMS is the
>> same.
>>
>
> Unless something has changed, it's all done inside the kernel by
> cooperating drivers buried inside the kernel. As far as I am aware,
> there is absolutely no process context involved (not even an ACP)
> when sending a PING reply.
>
> There is a TCPIP$INETACP process but that is basically the UCX
> version of inetd.
>
> Simon.
>

Agreed, but some other process has to call that os function to
send the ping and monitor the result. I guess the real issue
here is how easy it is for an attacker to start a new process
with elevated privileges. If you stop that, you prevent a whole
range of possible attacks.

All modern operating system have many processes started and
running from boot time. One of the ways to make an OS more
secure is to disable all unwanted services and daemons to
reduce the possible attack surface. How many people actually
do that simple stuff though ?...

Regards,

Chris

Stephen Hoffman

unread,
Oct 12, 2017, 7:31:08 PM10/12/17
to
On 2017-10-12 21:55:00 +0000, Chris said:

> On 10/12/17 20:09, Simon Clubley wrote:
>> Unless something has changed, it's all done inside the kernel by
>> cooperating drivers buried inside the kernel. As far as I am aware,
>> there is absolutely no process context involved (not even an ACP) when
>> sending a PING reply....
>
> Agreed, but some other process has to call that os function to send the
> ping and monitor the result. I guess the real issue here is how easy it
> is for an attacker to start a new process with elevated privileges. If
> you stop that, you prevent a whole range of possible attacks.

AFAIK, the ICMP server doesn't have process context on OpenVMS. It's
driver based, IIRC. Not that the implementation details here
particularly matter, outside of a personal preference to avoid having
packet parsers in the kernel or in process-local privileged code. As
for app isolation, that's a tougher issue and what OpenVMS offers at
present is not particularly competitive in that regard, tends toward
harder to audit, and is not particularly easy to use nor to implement.

> All modern operating system have many processes started and running
> from boot time. One of the ways to make an OS more secure is to disable
> all unwanted services and daemons to reduce the possible attack
> surface. How many people actually do that simple stuff though ?...

That's a very common piece of the effort, certainly. Scanning for
checksums, both OpenVMS and authorized installations, and app signing,
too. I've suggested eliminating insecure network services as is
becoming common on some other platforms, or of requiring additional
steps and passing through additional warnings to allow the site to
enable those insecure network services. Also of integrating the
network services into the base distro as conditional code (everywhere)
is more complex and more difficult to test. Also of overhauling or
updating or replacing existing and problematic sequences such as the
typical IPv4/IPv6/DNS/SSL/PKE/CRL/pinning sequences with libraries or
frameworks that make this easier to get right and harder to get wrong.
I've also suggested implementing an OpenVMS analog to the BSD pledge()
to the VSI folks, as an intermediate step between what's available now
and the eventual implementation of more recent app-isolation
capabilities. The pledge() call is also a nice fit for dropping
privileges in the context of installed privileged images, a step which
is comparatively poorly documented but something generally recommended.

http://man.openbsd.org/OpenBSD-current/man2/pledge.2

The whole of the current UIC and identifier and username stuff is a bit
of a dog's breakfast by current standards, too. Automating management
of that isn't any fun, when you're working with kitting and with
installs and deployments. Better integration with LDAP beyond
passwords and account status is needed, as well. More than a few other
areas lurk here, like ensuring that VAFS bootstraps can be from
encrypted storage, for instance.

Make secure apps easier, and make secure servers the default. Lots of
work here. But the x86-64 port is more important, as is achieving
sustained and increasing profits.

Arne Vajhøj

unread,
Oct 12, 2017, 8:29:58 PM10/12/17
to
On 10/12/2017 10:19 AM, Chris wrote:
> Well, if you can't trust your staff, you have much bigger
> problems and no amount of system security will fix that. The
> external threat is by far the biggest problem, especially if
> you have internet facing X86 boxes, irrespective of the OS...

But you can't trust your staff.

That is why accounts, password, privileges and those 60's/70's
ideas was invented.

I don't know the ratio internal vs external, but internal
threats are definitely relevant.

Arne

Arne Vajhøj

unread,
Oct 12, 2017, 8:39:01 PM10/12/17
to
On 10/12/2017 8:25 AM, Simon Clubley wrote:
> On 2017-10-11, Kerry Main <kemain...@gmail.com> wrote:
>> Given this scenario, yes there is always some risk, but the probability
>> is extremely low. Hence, the added "insurance" costs are hard to
>> justify.
>
> Long term, security by obscurity does not work and only gives you
> a false sense of security.

Security by obscurity is definitely bad security.

> Anything found in x86-64/IA64/Alpha could work on VAX as well and your
> out of software support VAX now has a vulnerability that you may have
> no way to fix. Now what do you do ?
>
> Running a VAX in production is like running Windows XP or an old
> Windows Server version in production. If you decide to do that, you
> had better have a bulletproof operating environment for that server
> so that it doesn't matter how many vulnerabilities are discovered
> and become public knowledge.

If you have a true/false approach to security then an old VMS VAX and
a somewhat old WinXP are the same.

But if you have a probability & priority approach to security then
the probability of an old VMS VAX being successfully attacked is a
lot smaller than a somewhat old WinXP are.

That does not make the old VMS VAX good from a security perspective.
But I would say that it should impact priorities. For most organizations
keeping everything constantly as secure as possible is not realistic.
Funding, resources, business constraints etc. all limit what is
realistic. So you prioritize what need to be fixed based on the
risk.

That old VMS VAX system should be on the TODO list, but in many
cases it may not go to the top of the list.

Arne

Arne Vajhøj

unread,
Oct 12, 2017, 8:49:46 PM10/12/17
to
On 10/12/2017 1:47 PM, Simon Clubley wrote:
> On 2017-10-12, David Froble <da...@tsoft-inc.com> wrote:
>>
>> There needs to be "something", such as a process, job, and such.
>
> For some special cases, that something could always be in kernel mode,
> outside of process context.

I thought kernel mode had a process context and only
interrupts was system context?

Arne




Arne Vajhøj

unread,
Oct 12, 2017, 9:03:53 PM10/12/17
to
On 10/12/2017 10:11 AM, Chris wrote:
> What the posts here all miss is the fact that the vast majority of
> exploits depend on getting an executable binary running on the
> target, so if it's not X86, it doesn't run. Just how many exploits
> currently exist that would run on pdp, vax, alpha or even
> itanium ?. It's one of the reasons why I run non x86 servers here,
> as they are inherently more secure by default. Not saying it isn't
> an issue, but the risk is minimal with correctly configured
> systems and firewalling...

I don't think that is correct.

Exploits involving native binaries are a tiny fraction
of security vulnerabilities today.

SQL injection
session hijacking
XSS
CSRF
etc.

The well-known Equifax hack would have worked the
same way no matter the processor of the host.

Arne

Johnny Billquist

unread,
Oct 13, 2017, 2:43:27 AM10/13/17
to
See. This is exactly what I mean. People can't even grasp the concept. :-)

Johnny

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol

Johnny Billquist

unread,
Oct 13, 2017, 3:05:03 AM10/13/17
to
I know what point you were trying to make, but that shows you missed my
point.

Yes, any program running is always associated with a UIC (or some kind
of identifier). But my point was that in RSX (and some other OSes) you
are not forced to run the login program the first thing you do when
connecting to the system, which forces you to log in.
In RSX, you are immediately given a CLI prompt when connected, and you
are free to give any command at once, without logging in. Logging in is
the procedure of identifying yourself to the system, and thereby being
assigned what rights and capabilities you have, or are allowed to access.

Script kiddies assume that the first thing happening when connecting to
a system is that it will prompt you for a username. Thus they get very
confused by a system which just gives a prompt, and where you actually
explicitly have to tell it that you want to log in.

This has close to nothing to do with the fact that any program run is
running under some identity or other.

And without logging in, the system do not know who you are, or what
rights you should have. However, not being logged in is a rather special
state, so instead there is a much larger restriction on what you are
allowed to do. So without logging in, there are preciously few things
you actually can do, but there are a couple of things possible, such as
actually logging in. But also getting help, which, among other things,
can tell you have to actually go about logging in.

But the point is that you are not automatically thrown at the login
process, but given a CLI prompt, where you can give commands. This is
(really) one of the most confusing things for script kiddies. They get
totally lost when the system don't start by prompting you for a username.

Why you decided to pick on the fact that all proccesses have an
associated UIC when I was talking about login, I don't know. This is two
different things.

>> There needs to be "something", such as a process, job, and such.
>>
>> I seem to recall something in the past that allowed such a thing.
>> Can't remember what.  Damn senility.
>>
>> There was the multi-terminal stuff in RSTS, but, that was an existing
>> job controlling multiple terminals.
>
> No process has run on any OS I have ever worked on without
> someone owning it.

That don't make a terminal logged in. Even the login process is owned by
someone. Don't mean the user logging in is that identity that owns the
login process.

You also mentioned VMS startup. I don't know if you paid attention, but
the initial startup process is in fact logged in. The last thing it does
is logging out, which is when you see the logout message in the startup
sequence.

Same is true for RSTS/E and RSX. The startup is done as a logged in user.

Batch jobs create a logged in user. at command under Unix also run as a
logged in user. All very different from a not logged in terminal.

Johnny Billquist

unread,
Oct 13, 2017, 3:10:34 AM10/13/17
to
On 2017-10-12 14:29, Bill Gunshannon wrote:
> On 10/12/2017 03:05 AM, Johnny Billquist wrote:
>> On 2017-10-12 02:11, Bill Gunshannon wrote:
>>> On 10/11/2017 06:33 PM, George Cornelius wrote:
>>>> In article <f479up...@mid.individual.net>, Bill Gunshannon
>>>> You mean Johnny never ported his IP stack to RSTS???
>>>>
>>>
>>> Sadly, as far as I know, no.  If they ever release the source
>>> it might be fun to do it, though.  And put a web server on it
>>> like I have on the 6809 sitting next to me now.  :-)
>>
>> "They"? It's just me. And if you really want to try, just talk to me,
>> and we'll see if you can carry such a thing through.
>>
>
> No, I meant the source to RSTS.  "They" have it but I don't know
> if anyone even knows who "they" are or what their plans, if any,
> for the PDP-11 OSes is.

Oh! My mistake.
Well, I can answer that one too. Owner is XX2247 LLC. The man behind
that is Dave Carroll. He do not have any plans, as the original
agreement between DEC and Mentec have clauses giving DEC a degree of
control which limits what Mentec could do. That agreement is still in
effect, but now it's HP and XX2247. And since HP have no clue, it's
pretty much impossible to change that agreement, so it's stuck in limbo.
Until someone can get HP to sign a new paper that is. After that, I
think it's fair to say that it would be nice to get people to legally
run these systems finally. I do not officially speak for XX2247, but I'm
sortof involved.

So not really much of a "they" there either. :-)

Simon Clubley

unread,
Oct 13, 2017, 3:15:53 AM10/13/17
to
A device driver can queue up work for another device driver to do
without a process being involved.

Johnny Billquist

unread,
Oct 13, 2017, 3:16:27 AM10/13/17
to
Well, the obvious response to that is that new platforms are not secure
either. It's just either a case of you not yet knowing the threats, or
the noone yet knowing the threats.
In the latter case, you might be temporarily somewhat secure, but most
of the time it is the former case, in which case you just think you are
secure because you are running the latest and greatest, but in fact it's
not.

So, not really that much difference, if you really case about security.
The best you can do is try to avoid the known worst problems, and then
just pray, and have good backups offline.

And of course internal threats can never be solved through technical
solutions.

Bob Koehler

unread,
Oct 13, 2017, 9:45:55 AM10/13/17
to
In article <oroobi$57i$1...@gioia.aioe.org>, Chris <xxx.sys...@gfsys.co.uk> writes:
>
> Agreed, but some other process has to call that os function to
> send the ping and monitor the result.

No, it doesn't. OS kernels are perfectly capable of doing some
things without neeeded a process context.

Bob Koehler

unread,
Oct 13, 2017, 9:47:45 AM10/13/17
to
In article <orp1v2$h3i$1...@gioia.aioe.org>, =?UTF-8?Q?Arne_Vajh=c3=b8j?= <ar...@vajhoej.dk> writes:
>
> Security by obscurity is definitely bad security.

There are some really bad instances of security by obscurity in the
real world. But every password based, or RSA key based, ... security
implementation is depending on the obscurity of the password, or key,
...

Bob Koehler

unread,
Oct 13, 2017, 9:49:27 AM10/13/17
to
In article <orp2j7$hp7$1...@gioia.aioe.org>, =?UTF-8?Q?Arne_Vajh=c3=b8j?= <ar...@vajhoej.dk> writes:
>
> I thought kernel mode had a process context and only
> interrupts was system context?

The kernel does not have process context. That's why an ACP, which
is generally kernel mode code, but not built into the kernel, is
sometimes needed.

Getting the XQP running wihtout an ACP was a major piece of work.

David Froble

unread,
Oct 13, 2017, 9:55:37 AM10/13/17
to
Simon Clubley wrote:
> On 2017-10-12, Bill Gunshannon <bill.gu...@gmail.com> wrote:
>> On 10/12/2017 01:47 PM, Simon Clubley wrote:
>>> On 2017-10-12, David Froble <da...@tsoft-inc.com> wrote:
>>>> There needs to be "something", such as a process, job, and such.
>>>>
>>> For some special cases, that something could always be in kernel mode,
>>> outside of process context. For example, you don't create a process
>>> everytime you send a PING reply...
>>>
>> Who owns the daemon returning the PING reply? Even kernel
>> processes on Unix belong to someone. I am sure VMS is the
>> same.
>>
>
> Unless something has changed, it's all done inside the kernel by
> cooperating drivers buried inside the kernel. As far as I am aware,
> there is absolutely no process context involved (not even an ACP)
> when sending a PING reply.

Since TCP/IP is NOT part of VMS, then I'm going to suggest that there is nothing
in VMS which replies to a ping.

> There is a TCPIP$INETACP process but that is basically the UCX
> version of inetd.

I'm too lazy to try, but, I'm guessing that if TCP/IP is not started, a VMS
system will not respond to a ping.

David Froble

unread,
Oct 13, 2017, 10:02:06 AM10/13/17
to
Well, I'm not going to agree or deny that, cause I don't know.

However, on VMS, you are at a terminal and hit a CR. Who gets it? I believe
the terminal driver, which is not a process, as far as I know, handles that
interrupt. What all the terminal driver can do, I don't know. But at some
point a process is created to run loginout. Don't know if any "owner" is set up
or designated at that time.

After casting an eye at the I&DS book, Dave decides it's too nice a day for
extensive reading ....

Chris

unread,
Oct 13, 2017, 10:22:55 AM10/13/17
to
At least for unix, ping is a command line application that calls
system services.

If you are running inetd at the receiving end, a ping packet results
in a fork to a new process to handle the ping request, as it does for
other inetd network services. inetd is a daemon started up at boot
time and hands off requests to the appropriate service, then resumes
listening for the next request. So yes, new processes are created and
die all the time.

If we are being picky, even the kernel is a set of cooperating
processes...

Regards,

Chris

Chris

unread,
Oct 13, 2017, 10:29:00 AM10/13/17
to
On 10/12/17 17:43, Simon Clubley wrote:
> On 2017-10-12, Bill Gunshannon<bill.gu...@gmail.com> wrote:
>> On 10/12/2017 10:11 AM, Chris wrote:
>>>
>>> What the posts here all miss is the fact that the vast majority of
>>> exploits depend on getting an executable binary running on the
>>> target, so if it's not X86, it doesn't run. Just how many exploits
>>> currently exist that would run on pdp, vax, alpha or even
>>> itanium ?.
>>
>
> That's only true when you are targeting Linux and Windows.
>
> If you are targeting VMS, you write shellcode for the architectures
> that VMS runs on.
>
> You may also find that if you discover a vulnerability in Alpha VMS
> then the same vulnerability might also work on VAX VMS if a VAX
> version of the shellcode is produced.
>
> When VMS on x86-64 becomes available, then you are likely to find
> a good number of people probing it, especially given the security
> related language on the VSI website. You may discover that those
> same flaws may also work on earlier VMS architectures.
>
>> Well, I think the VAX and PDP might be fairly safe, but I have dealt
>> with numerous exploits that were PHP based so any machine running PHP
>> is exploitable.
>>
>
> VMS on VAX is not safe.
>
> Simon.
>


What do you mean by shell code and how does it get into the system in
the first place ?...

Regards,

Chris

Bill Gunshannon

unread,
Oct 13, 2017, 10:38:17 AM10/13/17
to
On 10/13/2017 10:22 AM, Chris wrote:
> On 10/13/17 13:43, Bob Koehler wrote:
>> In article<oroobi$57i$1...@gioia.aioe.org>,
>> Chris<xxx.sys...@gfsys.co.uk>  writes:
>>>
>>> Agreed, but some other process has to call that os function to
>>> send the ping and monitor the result.
>>
>>     No, it doesn't.  OS kernels are perfectly capable of doing some
>>     things without neeeded a process context.
>>
>
> At least for unix, ping is a command line  application that calls
> system services.
>
> If you are running inetd at the receiving end, a ping packet results
> in a fork to a new process to handle the ping request, as it does for
> other inetd network services. inetd is a daemon started up at boot
> time and hands off requests to the appropriate service, then resumes
> listening for the next request. So yes, new processes are created and
> die all the time.

Ummm... No. Ping is at the ICMP layer and is part of the TCP/IP
"kernel". inetd is not involved and no new process is spawned.
If that were the case ping would make an even more amazing DOS
tool than it already is. :-)

bill

Bill Gunshannon

unread,
Oct 13, 2017, 10:42:02 AM10/13/17
to
Well, to me, shell would mean any kind of script that can be run
on the remote system, thus my comment regarding PHP. As for how
they get it on, PHP provides that capability by default. All it
needs is a writable directory to put it in that is not executable
blocked. (thus the reason any sys admin worth his salt makes /tmp
a separate mounted partition with noexec as one of the options.)

bill


Stephen Hoffman

unread,
Oct 13, 2017, 10:56:12 AM10/13/17
to
On 2017-10-13 14:02:02 +0000, David Froble said:

> However, on VMS, you are at a terminal and hit a CR. Who gets it? I
> believe the terminal driver, which is not a process, as far as I know,
> handles that interrupt. What all the terminal driver can do, I don't
> know. But at some point a process is created to run loginout. Don't
> know if any "owner" is set up or designated at that time.
>
> After casting an eye at the I&DS book, Dave decides it's too nice a day
> for extensive reading ....

BOT.

Kernel-mode code on OpenVMS can operate in conjunction with, or without
an associated process context. OpenVMS device drivers can be quite
different than drivers on other platforms, and are often rather more
complex. Device driver and execlets and UWSS code and other
system-level code can operate with or without an associated process,
depending on the specific sequences and requirements. Drivers can and
do continue to perform (most) operations during normal operations and
can continue (most) operations through a cluster quorum hang; in
execution environments that've variously been referred to as driver or
system or interrupt context. Device drivers need a process context
for certain operations such as RMS (that's not required for echoing a
ping) and that's usually an ACP or a process that's assigned a channel
to the specified device, and can require process context for copying to
or from application I/O buffers into kernel buffers or for directly
reading or writing the user buffers while interacting with the target
I/O device,. Drivers can certainly also "borrow" arbitrary process
contexts and usually through what are known as traps, though borrowing
a random process context not something generally recommended, It's
also quite possible that there is no process scheduled and running
while a device driver is active, too.

OpenVMS networking is utterly archaically organized and packaged, with
a 1990-era view of IP networking stacks. Microsoft Windows 95 got this
packaging right, OpenVMS still hasn't adapted. Kernel IP access was
only recently acquired by OpenVMS and with only those minimal parts
necessary for unauthenticated unencrypted clustering over UDP (and not
over TCP, nor with TLS or DTLS support, nor any sort of encryption,
among other omissions. User IP networking remains available solely
via an add-on package, and very far from integrated with all the
management and ISV and app and end-user baggage that disjoint and
ad-hoc approach entails. OpenVMS once featured best-of-class
networking integration and support and it was commonplace to insinuate
a VAX/VMS box into a network to allow communications among other hosts,
and alas now rather more comparable to a dog's breakfast.

ICMP traffic differs from TCP or UDP traffic, lacking an associated
source and destination port among other details. Processing an ICMP
ping echo reply doesn't need a process context, and any particular IP
stack can choose to use driver context and no process context for the
echo, or can use an ACP (which is a driver-associated process), or
process context for ICMP traffic. It's also quite possible for
systems to generate ICMP ping echo request traffic, and that too can
have either an associated process context, or the ICMP ping request and
echo reply can hypothetically be part of a kernel-based keep-alive used
within some hypothetical cluster-related networking activity, or other
such integrated monitoring or troubleshooting and recovery processing.

Process context and privileges and UICs and identifiers are how OpenVMS
tries to isolate activities and that works well against older sorts of
exploits, and that works pretty well for older environments, but it
also assumes perfection of the kernel and of the applications and the
frameworks, and assumes there won't be attempts to insinuate new or to
repurpose existing executable code, rather than assuming there'll be
problems and working to isolate those. I'm skeptical of the existing
isolation mechanisms and the antique software update mechanisms, given
what we've all seen around our abilities to write and secure code,
apply patches quickly, and isolate and route around failed code or
failed servers; the ever-popular traditional app uptime is hard enough
to achieve given the software and hardware problems that can arise, and
maintaining uptime and integrity and security against adversaries is
harder. The lack of integrated authentication and the lack of
transport encryption, and the still-prevalent availability and use of
insecure transports— those concentric "four rings" diagrams
unfortunately omit the network, and that's now an integral part of
effectively all of our computing environments — makes for rather easier
attacks, irrespective of whether the ICMP echo replies originate from
within a driver or if the echo requests are passed through drivers and
into and then returned through drivers from a process context. That's
all also ignoring the relative difficulty of achieving isolation — roll
your own pledge call, determine whether or not your files are as
distributed or have been compromised, etc — when (not if) some new
vulnerability is identified in a component.

EOT.

Stephen Hoffman

unread,
Oct 13, 2017, 11:01:56 AM10/13/17
to
On 2017-10-13 14:28:58 +0000, Chris said:

> On 10/12/17 17:43, Simon Clubley wrote:
>> If you are targeting VMS, you write shellcode for the architectures
>> that VMS runs on.
>
> What do you mean by shell code

https://en.wikipedia.org/wiki/Shellcode

> and how does it get into the system in the first place ?...

https://en.wikipedia.org/wiki/Vulnerability_(computing)

Exploits can be written in any language that may be available on the
target, and are not limited to architecture-specific machine code.

https://en.wikipedia.org/wiki/Shellshock_(software_bug) among (many)
other examples.

Chris

unread,
Oct 13, 2017, 11:14:41 AM10/13/17
to
Right, bad example. Certainly true for things like telnet, ftp
etc. Even ping forks a new process to handle the request.
Otherwise, how would it be possible to ping a host from two
different clients at once without error ?...

Regards,

Chris

Jan-Erik Soderholm

unread,
Oct 13, 2017, 11:28:30 AM10/13/17
to
How is it possible for inetd to fork two (or more) processes
"at once" (whatever *that* is) without error?

I would guess that it takes the same amount of processing
to fork a new process as it is to just reply to the ping.

I do not like concepts like "at once" or "at the same time".
There is never something like "the same time" if you look at
it closely enough...



> Regards,
>
> Chris

Chris

unread,
Oct 13, 2017, 11:55:56 AM10/13/17
to
The issue is still how to get a script running on the target, but
having such an ability in PHP (Bill, upthread) suggests that PHP
and other scripting languages should be nowhere near a web facing
machine. Waste of time to say so, I guess, as that horse has already
gone.

Have a small private ftp and web server. The log files show just
how bad the PHP issue is. Dozens of log entries per day looking for
default config files, POST requests with binary data etc. Don't use
any scripting at all, just static read only html with appropriate
permissions system wide. Then, compiled C with encrypted link to a
mysql server on another machine. Sure, still issues, but it
would take a very determined hacker to disassemble the binaries to
get any info on the functionality, or even the server ip address,
which is created on the fly and buffer cleared for each access.

Here's a sample from the logfile:

[11/Oct/2017:16:55:22 +0000] "GET /muieblackcat HTTP/1.1" 404 345 "-" "-"
[11/Oct/2017:16:55:22 +0000] "GET //_phpmyadmin/scripts/setup.php
HTTP/1.1" 404 345 "-" "-"
[11/Oct/2017:16:55:23 +0000] "GET //admin/phpmyadmin/scripts/setup.php
HTTP/1.1" 404 345 "-" "-"
[11/Oct/2017:16:55:23 +0000] "GET //admin/pma/scripts/setup.php
HTTP/1.1" 404 345 "-" "-"
[11/Oct/2017:16:55:23 +0000] "GET //admin/scripts/setup.php HTTP/1.1"
404 345 "-" "-"
[11/Oct/2017:16:55:24 +0000] "GET
//administrator/components/com_joommyadmin/phpmyadmin/scripts/setup.php
HTTP/1.1" 404 345 "-" "-"
[11/Oct/2017:16:55:24 +0000] "GET
//apache-default/phpmyadmin/scripts/setup.php HTTP/1.1" 404 345 "-" "-"
[11/Oct/2017:16:55:25 +0000] "GET //blog/phpmyadmin/scripts/setup.php
HTTP/1.1" 404 345 "-" "-"
[11/Oct/2017:16:55:25 +0000] "GET //cpanelphpmyadmin/scripts/setup.php
HTTP/1.1" 404 345 "-" "-"
[11/Oct/2017:16:55:26 +0000] "GET //cpphpmyadmin/scripts/setup.php
HTTP/1.1" 404 345 "-" "-"
[11/Oct/2017:16:55:26 +0000] "GET //db/scripts/setup.php HTTP/1.1" 404
345 "-" "-"
[11/Oct/2017:16:55:26 +0000] "GET //dbadmin/scripts/setup.php HTTP/1.1"
404 345 "-" "-"
[11/Oct/2017:16:55:27 +0000] "GET //forum/phpmyadmin/scripts/setup.php
HTTP/1.1" 404 345 "-" "-"
[11/Oct/2017:16:55:28 +0000] "GET //myadmin/scripts/setup.php HTTP/1.1"
404 345 "-" "-"
[11/Oct/2017:16:55:28 +0000] "GET //mysql/scripts/setup.php HTTP/1.1"
404 345 "-" "-"
[11/Oct/2017:16:55:28 +0000] "GET //mysqladmin/scripts/setup.php
HTTP/1.1" 404 345 "-" "-"
[11/Oct/2017:16:55:29 +0000] "GET //php/phpmyadmin/scripts/setup.php
HTTP/1.1" 404 345 "-" "-"
[11/Oct/2017:16:55:29 +0000] "GET //phpadmin/scripts/setup.php HTTP/1.1"
404 345 "-" "-"
[11/Oct/2017:16:55:29 +0000] "GET //phpmyadmin/scripts/setup.php
HTTP/1.1" 404 345 "-" "-"
[11/Oct/2017:16:55:30 +0000] "GET //php-my-admin/scripts/setup.php
HTTP/1.1" 404 345 "-" "-"
[11/Oct/2017:16:55:30 +0000] "GET //phpMyAdmin2/scripts/setup.php
HTTP/1.1" 404 345 "-" "-"
[11/Oct/2017:16:55:31 +0000] "GET //phpMyAdmin-2/scripts/setup.php
HTTP/1.1" 404 345 "-" "-"
[11/Oct/2017:16:55:31 +0000] "GET //phpMyAdmin3/scripts/setup.php
HTTP/1.1" 404 345 "-" "-"
[11/Oct/2017:16:55:32 +0000] "GET //pma/scripts/setup.php HTTP/1.1" 404
345 "-" "-"
[11/Oct/2017:16:55:32 +0000] "GET //scripts/setup.php HTTP/1.1" 404 345
"-" "-"
[11/Oct/2017:16:55:32 +0000] "GET //typo3/phpmyadmin/scripts/setup.php
HTTP/1.1" 404 345 "-" "-"
[11/Oct/2017:16:55:33 +0000] "GET //web/phpMyAdmin/scripts/setup.php
HTTP/1.1" 404 345 "-" "-"
[11/Oct/2017:16:55:33 +0000] "GET //web/scripts/setup.php HTTP/1.1" 404
345 "-" "-"
[11/Oct/2017:16:55:34 +0000] "GET //websql/scripts/setup.php HTTP/1.1"
404 345 "-" "-"
[11/Oct/2017:16:55:34 +0000] "GET //xampp/phpmyadmin/scripts/setup.php
HTTP/1.1" 404 345 "-" "-"


[28/Sep/2017:16:27:13 +0000] "POST //%63%67%69%2D%62%69%6E/
%70%68%70?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63
%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65
%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75

<snipped>

%69%6E%70%75%74+%2D%6E HTTP/1.1" 400 349 "-" "-"

It's a balance of risk. That is, how much effort it takes to crack
the system, vs the potential reward. Serious criminals with a lot of
resources won't bother hacking a website with no payoff. The rest,
script kiddies etc, should be much easier to filter out using good
practice...

Regards,

Chris

Chris

unread,
Oct 13, 2017, 12:15:28 PM10/13/17
to
On 10/13/17 15:28, Jan-Erik Soderholm wrote:

>
> How is it possible for inetd to fork two (or more) processes
> "at once" (whatever *that* is) without error?
>
> I would guess that it takes the same amount of processing
> to fork a new process as it is to just reply to the ping.
>
> I do not like concepts like "at once" or "at the same time".
> There is never something like "the same time" if you look at
> it closely enough...
>
>


Think of inetd as a post sorting office. All letters end up
there from the network, are sorted into destinations and sent
on their way. inetd, receives requests from the network,
works out which service is being used and starts the correct
program, or process, that knows how to satisfy the request.

If it were to handle the request by itself, it would have
to block all others during that time, but there are typically
many different network ops running at once, so it makes sense
to separate the functionality into categorisation and
execution. It also means that any number of ftp requests,
for example, can be serviced at once, since each request
results in a new process creation for the lifetime of the ftp
login.

Of course none of that happens at once in any multitasking
os, but is time sliced by the scheduler at millisecond rate
to give that effect...

Regards,

Chris


Stephen Hoffman

unread,
Oct 13, 2017, 12:40:28 PM10/13/17
to
On 2017-10-13 15:55:52 +0000, Chris said:

> On 10/13/17 15:01, Stephen Hoffman wrote:
>> On 2017-10-13 14:28:58 +0000, Chris said:
>>
>>> On 10/12/17 17:43, Simon Clubley wrote:
>>>> If you are targeting VMS, you write shellcode for the architectures
>>>> that VMS runs on.
>>>
>>> What do you mean by shell code
>>
>> https://en.wikipedia.org/wiki/Shellcode
>>
>>> and how does it get into the system in the first place ?...
>>
>> https://en.wikipedia.org/wiki/Vulnerability_(computing)
>>
>> Exploits can be written in any language that may be available on the
>> target, and are not limited to architecture-specific machine code.
>>
>> https://en.wikipedia.org/wiki/Shellshock_(software_bug) among (many)
>> other examples.
>
> The issue is still how to get a script running on the target, but
> having such an ability in PHP (Bill, upthread) suggests that PHP and
> other scripting languages should be nowhere near a web facing machine.
> Waste of time to say so, I guess, as that horse has already gone.

No argument, but the holes are legion, and not restricted to php.
WANK on OpenVMS from years ago, though that one has long been plugged.
And the exploits vary widely. Some of the shellcode — some exploits
— are architecture and platform specific, and some are portable. Just
as developers can choose and use all sorts of languages, so too do the
folks in the business of writing exploits. Folks have gotten
breached secondary to flaws in parsers (including parsers in kernel
code), and secondary to flaws in many other parts of their respective
platforms. I've cleaned up OpenVMS systems after some folks were
using Perl-based DoS tools were run and where targeting other hosts
from OpenVMS, and also with various reflective attacks using OpenVMS,
and have seen spam runs using OpenVMS systems. (There's an utterly
stupid default in the current OpenVMS SMTP mail server, too.)

In response to these, some folks focus on achieving perfection, whether
it's with server uptime or security or always-current-versions or
add-on anti-malware tools or otherwise — and not enough time pondering
and addressing what we have now and with what we're working with and
what we've been encountering. Of forgetting that we still have to
patch and upgrade and replace servers while maintaining availability
and integrity and uptime and security, and that we sometimes and
unfortunately variously forget to upgrade specific pieces and parts
expeditiously.

Or that we'll sometimes have wholly new bugs (e.g. OpenSSL gets
security updates and OpenVMS tends to be slow to deploy those patches,
or some previously unknown or unrecognized or unaddressed
vulnerability), but — given the other flaws lurking in the
configurations and implementations of many OpenVMS sites — exploits for
some of the more clever sorts of exploits for latent flaws are not
something that most of us will soon encounter. For many of us, there
are easier ways to exploit our OpenVMS systems, and/or we're not worth
the costs of exposing the better-grade exploits. But I digress.

Rather than assuming that we'll ever reach perfection, we're better off
designing and building our tools and frameworks and platforms to
isolate and contain and automate the required processing, the requisite
backups, and faster reloads and recoveries. To isolate and contain
the breaches. As an example here, the OpenVMS patch process can
itself be most charitably be considered to be needing some work. As
another example, a executable might require additional system or API or
file access while initializing, but then doesn't need that access after
initialization has completed.

Security is a really rather interesting area of computing, and with
completely different considerations than those familiar to operations
and app development and kernel development folks. The "bugs" that
we're encountering in that context are effectively far more variable,
pernicious, hostile and adaptive, and the developers that are
introducing those "bugs" might well be more skilled or better funded
than are our own efforts.

Chris

unread,
Oct 13, 2017, 12:46:32 PM10/13/17
to
On 10/12/17 15:07, Paul Sture wrote:

>
> But, a bit like running sshd on a non-standard port, you cut out the
> script kiddies (and in that case the size of your log files) in one fell
> swoop.
>
> You won't defeat the determined and skilled bad guys, but you will
> make it more difficult for them to hide in the noise generated by the
> others. Anything which increases your odds of detecting an attack
> is a good thing, no?
>


It's a balance of risk and you have to assume that any
system can be broken, given enough time and resources. It's foolish
to think otherwise, but the level of security should match the
risk in terms of inconvenience, financial or other loss to the owners.
While it may be easy to keep out script kiddies from a small website,
financial organisations, for example, attract a different kind of well
funded and resourced hackers. No one size fits all solution...

Regards,

Chris

Bill Gunshannon

unread,
Oct 13, 2017, 12:58:04 PM10/13/17
to
If you are still talking about on the server end, it forks nothing.
ICMP are handled directly within the TCP/IP code. The request forks
a new process because it is just a user level command. The response
is a privileged action handled directly within the TCP/IP code itself.
And even it can be stopped as has been done by many admins.

bill


Simon Clubley

unread,
Oct 13, 2017, 1:22:55 PM10/13/17
to
On 2017-10-13, Chris <xxx.sys...@gfsys.co.uk> wrote:
>
> Right, bad example. Certainly true for things like telnet, ftp
> etc. Even ping forks a new process to handle the request.
> Otherwise, how would it be possible to ping a host from two
> different clients at once without error ?...
>

The ping _client_ is a normal user process, but all the information the
receiver of the ping request needs in order to reply to the packet is in
the headers of the incoming packet; no process context is required by
the receiver.

ICMP is a low level protocol that is usually used for communicating
errors and required actions. ping is just the most visible use of
ICMP:

https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol

Because of its normal low level error handling job, the correct place
for generating ICMP responses is down in the kernel part of the TCP/IP
stack.

Simon Clubley

unread,
Oct 13, 2017, 2:01:57 PM10/13/17
to
On 2017-10-13, Chris <xxx.sys...@gfsys.co.uk> wrote:
> On 10/12/17 17:43, Simon Clubley wrote:
>>
>> If you are targeting VMS, you write shellcode for the architectures
>> that VMS runs on.
>>
>> You may also find that if you discover a vulnerability in Alpha VMS
>> then the same vulnerability might also work on VAX VMS if a VAX
>> version of the shellcode is produced.
>>
>> When VMS on x86-64 becomes available, then you are likely to find
>> a good number of people probing it, especially given the security
>> related language on the VSI website. You may discover that those
>> same flaws may also work on earlier VMS architectures.
>>
>
> What do you mean by shell code and how does it get into the system in
> the first place ?...
>

Stephen has already posted a definition of shellcode.

As for how does it get into the system in the first place, the basic
idea is that the non-privileged user places the shellcode somewhere
and then tricks the privileged application into executing it.

Once you find an interactive process based exploitable shellcode
vulnerability on VMS, then it is a _lot_ easier to get the shellcode
running than on some other operating systems because VMS has some
very nice attacker-friendly features.

1) A process and all the images activated within the process share a
common address space which is not fully reset between different image
activations. This means that for an interactive session, a non-privileged
image can place shellcode within that process and that shellcode will be
directly reachable from the privileged image if you can trick the image
into running it.

On VMS, no messing around with placing the shellcode on the stack is
required when using an interactive process exploit. Very nice.

2) Some data-only areas within that shared process space are executable
even though they should only contain data. Very, very, nice.

3) VMS has well known buffers which live in that shared process space
which are user mode writable from an interactive process. Very, very, nice.

For those of you who still don't understand shellcode and how it
works be aware that I will be posting a little demo sometime during
the first week of November for Alpha (and maybe VAX).

The delay is because I am giving VSI Alpha customers some time to apply
the patch which fixes the problems I have discovered. That is why I have
not yet even mentioned the parts of VMS which have the issues this time.

This shellcode is benign and all it does is to print "Simon was here..."
on your terminal session before causing a register dump (although there
is some interesting information in the registers). However, I am concerned
that someone with deep VMS internals knowledge may be able to turn
it into a proper vulnerability which is why I am being cautious.

Chris

unread,
Oct 13, 2017, 2:04:44 PM10/13/17
to
On 10/13/17 16:58, Bill Gunshannon wrote:

>>
>> Right, bad example. Certainly true for things like telnet, ftp
>> etc. Even ping forks a new process to handle the request.
>> Otherwise, how would it be possible to ping a host from two
>> different clients at once without error ?...
>>
>
> If you are still talking about on the server end, it forks nothing.
> ICMP are handled directly within the TCP/IP code. The request forks
> a new process because it is just a user level command. The response
> is a privileged action handled directly within the TCP/IP code itself.
> And even it can be stopped as has been done by many admins.
>
> bill
>
>

It's been some time, but did check with Stevens before posting the
above. That wasn't clear, only saying that *most* implementations
support the ping server in the kernel. It didn't answer the question
as to how it handles multiple requests at once, but the general
method, as per inetd, is to offload and fork / spawn a new process
to handle the request. Otherwise, you could lose requests while
servicing the current one. Perhaps ping is a special case,
optimised for speed, but not enough info.

None of that negates the original assertion, that all code running
in a multitasking os runs within a defined process context...

Regards,

Chris


Stephen Hoffman

unread,
Oct 13, 2017, 5:26:31 PM10/13/17
to
On 2017-10-13 18:04:42 +0000, Chris said:

> It's been some time, but did check with Stevens before posting the above.

Not sure what that "Stevens" is in reference to; what resource or
posting you're referring to by that.

> That wasn't clear, only saying that *most* implementations support the
> ping server in the kernel.

> It didn't answer the question as to how it handles multiple requests at once...

On OpenVMS, a device driver can either generate its responses directly
within the driver or from within the driver interrupt routine, or can
generate and use fork processes to process the request, or can pass the
request to an ancillary control process (ACP) and which can require
both a mode change and a context switch, or can pass the request off to
a process that's either demand-started, started at boot, or managed as
a pool akin to what Apache does with its worker processes. Some
drivers have associated physical hardware, and others are
pseudo-drivers; software-only device drivers.

What specifically OpenVMS does for this specific case within HPE TCP/IP
Services or within the upcoming VSI TCPIP stack, I don't know. I've
not looked at the implementation of either of those two IP stacks, and
this is not the sort of stuff that tends to be documented. I have
done more than a little networking work in kernel mode, including with
the VCI API, and more than a little device driver coding and debug work
over the years.

Fork processes are not at all similar to what OpenVMS developers —
folks that are writing code and debugging code and working outside of
kernel and driver development — think of as processes.

> but the general method, as per inetd, is to offload and fork / spawn a
> new process to handle the request.

Possible, but for something as simple as an ICMP echo reply, an OpenVMS
process creation (whether through inetd or otherwise) with the mode
switch and the context switch would be more overhead than might be
preferred, and it's also mean interesting system loading behavior
secondary to the arrival of a flood of ICMP ping requests. Which is
why I'd expect that the IP device driver itself just answers the ping
request with an echo reply; why bother transferring data from kernel to
an outer mode, with the corresponding mode switch and probably also
process context switch? NIC driver to IP driver and back to NIC
driver and back out...

> Otherwise, you could lose requests while servicing the current one.

Drivers use constructs such as spinlocks, IPLs, fork locks and device
locks to prevent data corruptions or losses and to coordinate access to
critical sections, and use queues or fork processes to avoid request
loss.

Given that this is ICMP, the loss of a packet or three due to excessive
system loading is likely not going to be particularly disruptive
problem, nor a misbehavior that would be considered a fatal error.

> Perhaps ping is a special case, optimised for speed, but not enough info.

ICMP is comparatively simple traffic. Managing and buffering a TCP
stream is somewhat more involved, for instance.

> None of that negates the original assertion, that all code running in a
> multitasking os runs within a defined process context...

That assertion is incorrect. All code running in a multitasking OS can
be implemented by whatever particular design that multitasking OS
happens to implement. On the particular operating system known as
OpenVMS, code can be invoked without having any process context, and
other code can be invoked with or within process context; either from
system virtual space with a specific process context available, in
system virtual address space with who-knows-what in process virtual
address space possibly including 'nothing', or in process virtual
address space within process context. Process context is one of the
abstractions that's commonly used, and it's a familiar one But no, I
have no idea why some folks here in this thread are seemingly wrapped
around the axle about what's executing in a process context and what
isn't, either.

I'm not sure why anybody would be particularly interested in the
implementation details of ICMP ping might be, either. Beyond the
developers supporting the code involved. So long as a ping echo
request gets an echo reply, there's no security vulnerabilities, and
getting hit with a barrage of pings doesn't substantially degrade
server performance.

What a particular Unix stack does? Donno. Check with the folks that
better know that particular platform. I'd expect to find some
differences between different implementations too; I'd not expect that
Linux, BSD, DragonflyBSD, seL4 and Minix all implemented their
networking in the same way, for instance.

Apropos of some of the more general discussions of around the different
sorts of kernel designs and implementation languages available for
same, there's _The Case for Writing a Kernel in Rust_ from last month
or so — and no, I don't expect a kernel rewrite on OpenVMS, nor would I
expect the existing development team would seek ti migrate to new
implementation languages.
http://www.cs.virginia.edu/~bjc8c/papers/levy17rustkernel.pdf

Chris

unread,
Oct 13, 2017, 7:00:05 PM10/13/17
to
On 10/13/17 21:26, Stephen Hoffman wrote:

Thanks for the detailed reply.

>
> Not sure what that "Stevens" is in reference to; what resource or
> posting you're referring to by that.

Richard W Stevens network series, which includes the Vol 1 and 2
of the TCP/IP Illustrated books, fairly os agnostic, and the Unix
Network Programming book. Very extensive and thorough treatment and
by some considered to be the standard reference texts on the subject.

>
> Fork processes are not at all similar to what OpenVMS developers
\u2014 folks
> that are writing code and debugging code and working outside of kernel
> and driver development \u2014 think of as processes.

Semantics here I guess, but many people would consider a process to be
an independent piece of code, data and communication pathways, that can
be started, stopped, put to sleep etc, under the control of the scheduler,

>
> Possible, but for something as simple as an ICMP echo reply, an OpenVMS
> process creation (whether through inetd or otherwise) with the mode
> switch and the context switch would be more overhead than might be
> preferred, and it's also mean interesting system loading behavior
> secondary to the arrival of a flood of ICMP ping requests. Which is why
> I'd expect that the IP device driver itself just answers the ping
> request with an echo reply; why bother transferring data from kernel to
> an outer mode, with the corresponding mode switch and probably also
> process context switch? NIC driver to IP driver and back to NIC driver
> and back out...

The problem is that icmp is a network layer level 3, IP function, as it
must be routable. There's a whole raft of code under that down to the
hardware to traverse to get the ping reply out on the wire. Depends on
the system design I guess. Some systems may have all that within the
network driver, some not.

>
> Given that this is ICMP, the loss of a packet or three due to excessive
> system loading is likely not going to be particularly disruptive
> problem, nor a misbehavior that would be considered a fatal error.

Perhaps, but ping is designed to be reliable tool that loses no
packets. Even a single reply loss is often indicative of a network
hardware problem.

>
> That assertion is incorrect. All code running in a multitasking OS can
> be implemented by whatever particular design that multitasking OS
> happens to implement.

Must be semantics again, because apart from interrupts, all code run
must run in process context, or be called from it. What else is there ?.

>
> I'm not sure why anybody would be particularly interested in the
> implementation details of ICMP ping might be, either.

This started because I made a statement about ping implementation
which was challenged and one thing leads to another, threads drift
etc.

>
> Apropos of some of the more general discussions of around the different
> sorts of kernel designs and implementation languages available for same,
> there's _The Case for Writing a Kernel in Rust_ from last month or so
\u2014
> and no, I don't expect a kernel rewrite on OpenVMS, nor would I expect
> the existing development team would seek ti migrate to new
> implementation languages.
> http://www.cs.virginia.edu/~bjc8c/papers/levy17rustkernel.pdf

I dunno, we already have enough languages to get programmers into
trouble with and it's a serious effort to become really fluent
in any of them. Do we really need any more untried examples ? :-)...

Regards,

Chris

Johnny Billquist

unread,
Oct 13, 2017, 7:20:11 PM10/13/17
to
We could have long discussions on how things work in different OSes, and
at different layers. But that would quickly drift quite far from what
might be relevant here.

Suffice to say that you have not understood what ICMP is, and how it
works. You can have user programs and tools which makes use of ICMP,
meaning there is a process involved in the client side of things, but
ICMP is pretty much stateless, and all done deep down inside the network
layers. There are never any process involved in the actual processing of
the ICMP traffic, unless you might look at something like an ACP being
involved in network traffic in general.

If you send an ICMP echo request to a host, the ICMP protocol layer will
reflect that packet back right away down in the network layers without
it ever coming as far as to inetd, or anything similar.

And that is pretty much the way it has to be, because the main purpose
of ICMP is as the error communication channel for the IP traffic. SO it
hooks into the IP layer in TCP/IP, but is also used by UDP and TCP at
times. And all this can happen for any and every packet that hits the
machine. This is long before you want to get any process involved in the
processing.

So, no. There is no process involved in ICMP processing. There is
normally a client program around which will send out ICMP echo request
packets, and receive the responses, but there is no corresponding server
side process or program.

Johnny

Johnny Billquist

unread,
Oct 13, 2017, 7:26:42 PM10/13/17
to
On 2017-10-13 02:29, Arne Vajhøj wrote:
> On 10/12/2017 10:19 AM, Chris wrote:
>> Well, if you can't trust your staff, you have much bigger
>> problems and no amount of system security will fix that. The
>> external threat is by far the biggest problem, especially if
>> you have internet facing X86 boxes, irrespective of the OS...
>
> But you can't trust your staff.
>
> That is why accounts, password, privileges and those 60's/70's
> ideas was invented.

That was not so much to protect against internal threats as external
ones. Staff usually do have usernames and passwords already, so it's
obviously not going to protect you.

> I don't know the ratio internal vs external, but internal
> threats are definitely relevant.

Internal threats are both more difficult, and potentially more damaging.
External threats are easier to work on solutions for. Internal ones
essentially needs more than just technical solutions.

Johnny

Chris

unread,
Oct 13, 2017, 7:30:07 PM10/13/17
to
I should give up, as it's not even worth the trouble to reply to that
load of assumptions and repeated stuff discussed upthread, if you
had taken the trouble to read it...

Regards,

Chris

Stephen Hoffman

unread,
Oct 13, 2017, 7:45:31 PM10/13/17
to
On 2017-10-13 23:00:01 +0000, Chris said:

> On 10/13/17 21:26, Stephen Hoffman wrote:

>> That assertion is incorrect. All code running in a multitasking OS can
>> be implemented by whatever particular design that multitasking OS
>> happens to implement.
>
> Must be semantics again, because apart from interrupts, all code run
> must run in process context, or be called from it. What else is there ?.

Code that has no associated process context. OpenVMS and other
systems can and do have inner-mode code that executes, and with no
associated process context. This situation is entirely normal and
expected for some of the code that executes on OpenVMS systems. This
design is also part of a typical implementation and experience and
trade-off that arises when designing most any kernel, and with the
ever-present choices and trade-offs among the implementation choices,
too. There's no right answer, and no single best design. Going into
and out of process context or of swapping among process contexts can be
slow. Yes, seL4 and Dragonfly BSD have gotten better about context
switches, and system hardware is faster, too, but nobody really likes
the overhead of the translation buffer and memory cache flushes that
can arise with these operations. Various kernels — including OpenVMS —
try to avoid unnecessary process context switches or unnecessary mode
changes in performance-critical code paths. But again, OpenVMS does
not have all of its code executing with an associated process context.

There's a write-up from a few years ago, around how long the kernel and
the drivers and the processor and network hardware can dally, before
there's packets getting dropped:

https://lwn.net/Articles/629155/

IEEE 802.3bs efforts around 200 GbE wired and 400 GbE optical standards
are seemingly headed for approval later this year, not that OpenVMS is
known for support for faster NICs, and we'll learn about the
performance of the VSI TCPIP stack as that becomes available to
customers over the next year or two.
http://www.vmssoftware.com/pdfs/VSI_Roadmap_20170925.pdf


>> http://www.cs.virginia.edu/~bjc8c/papers/levy17rustkernel.pdf
>
> I dunno, we already have enough languages to get programmers into
> trouble with and it's a serious effort to become really fluent in any
> of them. Do we really need any more untried examples ? :-)...

Yes, because the industry and the code and the tools we have all work
so wonderfully well.

The older folks around the comp.os.vms newsgroup will undoubtedly
remember the debates that raged around the move from the commonplace
usage of assembler to the common usage of 3GL/HLL tools, certainly.
Debates that included discussions of all the wasted performance that
HLL code could entail, for instance. Times and tools change.
Sometimes things change too fast. Sometimes not fast enough. And
there's always legacy code around. And never enough budget. Vendors
appear and vendors vaporize. Etc. But then I'd much rather having
folks trying new and different and sometimes wacky stuff than not, too.
I'd much rather work in C than assembler, too. Rust? Donno yet.
That's not yet an option on OpenVMS, but does fix some of the more
annoying limitations and hazards of C.

Arne Vajhøj

unread,
Oct 13, 2017, 7:47:27 PM10/13/17
to
On 10/13/2017 7:27 PM, Johnny Billquist wrote:
> On 2017-10-13 02:29, Arne Vajhøj wrote:
>> On 10/12/2017 10:19 AM, Chris wrote:
>>> Well, if you can't trust your staff, you have much bigger
>>> problems and no amount of system security will fix that. The
>>> external threat is by far the biggest problem, especially if
>>> you have internet facing X86 boxes, irrespective of the OS...
>>
>> But you can't trust your staff.
>>
>> That is why accounts, password, privileges and those 60's/70's
>> ideas was invented.
>
> That was not so much to protect against internal threats as external
> ones. Staff usually do have usernames and passwords already, so it's
> obviously not going to protect you.

????

Hopefully only those that need access to the system has
accounts. Leaving those without the need without
an account.

And hopefully very very few of those accounts has full
privs. Leaving the majority of those accounts limited
regarding what they can access and do on the system.

And my guess is that only a small fraction of VMS systems
back in the late 70's had any kind of external access.

>> I don't know the ratio internal vs external, but internal
>> threats are definitely relevant.
>
> Internal threats are both more difficult, and potentially more damaging.
> External threats are easier to work on solutions for. Internal ones
> essentially needs more than just technical solutions.

Technical solutions can help. D -> C2 -> B1 etc..

But there is definitely also some process involved.

Arne


Arne Vajhøj

unread,
Oct 13, 2017, 8:08:02 PM10/13/17
to
On 10/13/2017 11:55 AM, Chris wrote:
> The issue is still how to get a script running on the target, but
> having such an ability in PHP (Bill, upthread) suggests that PHP
> and other scripting languages should be nowhere near a web facing
> machine. Waste of time to say so, I guess, as that horse has already
> gone.

I can not follow the logic. It is usually a lot easier
to prevent code coming in via a high level script language
web application that some low level compiled language web
application.

And to prevent uploaded scripts from being run, then if
they can get a script up then they can probably get an
executable up also. And besides all systems usually have
one or more script languages installed. It would be tough
to remove DCL from VMS.

> Have a small private ftp and web server. The log files show just
> how bad the PHP issue is. Dozens of log entries per day looking for
> default config files, POST requests with binary data etc. Don't use
> any scripting at all, just static read only html with appropriate
> permissions system wide. Then, compiled C with encrypted link to a
> mysql server on another machine.

> Here's a sample from the logfile:
>
> [11/Oct/2017:16:55:22 +0000] "GET /muieblackcat HTTP/1.1" 404 345 "-" "-"
> [11/Oct/2017:16:55:22 +0000] "GET //_phpmyadmin/scripts/setup.php
> HTTP/1.1" 404 345 "-" "-"
> [11/Oct/2017:16:55:23 +0000] "GET //admin/phpmyadmin/scripts/setup.php
> HTTP/1.1" 404 345 "-" "-"

> [28/Sep/2017:16:27:13 +0000] "POST //%63%67%69%2D%62%69%6E/
> %70%68%70?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63
> %6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65
> %3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75
>
> <snipped>
>
> %69%6E%70%75%74+%2D%6E HTTP/1.1" 400 349 "-" "-"

I guess YMMV.

But I find it difficult to see why all those *rejected* requests
should be seen as a the language being bad.

Arne

Arne Vajhøj

unread,
Oct 13, 2017, 8:10:52 PM10/13/17
to
On 10/13/2017 3:15 AM, Simon Clubley wrote:
> On 2017-10-12, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>> On 10/12/2017 1:47 PM, Simon Clubley wrote:
>>> On 2017-10-12, David Froble <da...@tsoft-inc.com> wrote:
>>>>
>>>> There needs to be "something", such as a process, job, and such.
>>>
>>> For some special cases, that something could always be in kernel mode,
>>> outside of process context.
>>
>> I thought kernel mode had a process context and only
>> interrupts was system context?
>
> A device driver can queue up work for another device driver to do
> without a process being involved.

Then it will have to do it as interrupt.

Arne


Arne Vajhøj

unread,
Oct 13, 2017, 8:20:01 PM10/13/17
to
On 10/13/2017 9:46 AM, Bob Koehler wrote:
> In article <orp2j7$hp7$1...@gioia.aioe.org>, =?UTF-8?Q?Arne_Vajh=c3=b8j?= <ar...@vajhoej.dk> writes:
>>
>> I thought kernel mode had a process context and only
>> interrupts was system context?
>
> The kernel does not have process context.

If PSL.CURMOD=0 and PSL.IS=0 then it is kernel mode and it
better have a process context as the KSP will be pointing to
a kernel stack in P1 space.

Only PSL.CURMOD=0 and PSL.IS=1 (which means interrupts) should
use the interrupt stack in S0 space and therefore can work
in system context only.

At least that is my understanding.

Arne

Arne Vajhøj

unread,
Oct 13, 2017, 8:27:52 PM10/13/17
to
On 10/13/2017 9:45 AM, Bob Koehler wrote:
> In article <orp1v2$h3i$1...@gioia.aioe.org>, =?UTF-8?Q?Arne_Vajh=c3=b8j?= <ar...@vajhoej.dk> writes:
>> Security by obscurity is definitely bad security.
>
> There are some really bad instances of security by obscurity in the
> real world. But every password based, or RSA key based, ... security
> implementation is depending on the obscurity of the password, or key,
> ...

Traditionally "security by obscurity" is not considered to include
secret values but only information about algorithms, systems etc..

And if the secret values have a sufficient large range, then
that somewhat make sense.

Password length of 1 o 2 should probably be called security
by obscurity due to their lack of effectiveness.

Arne


terry-...@glaver.org

unread,
Oct 13, 2017, 11:41:00 PM10/13/17
to
On Wednesday, October 11, 2017 at 7:28:48 PM UTC-4, Johnny Billquist wrote:
> Nope. I have not. Might be possible, but would not be trivial. :-)
> But I know of another effort to do TCP/IP on RSTS/E, but that guy
> stopped after he had UDP running.

Would that be me, perchance? My stuff was all written as per-process user-level
code. There was no equivalent to inetd, and no centralized control of connections
so it would not be possible to create new server processes to handle incoming
requests. On the other hand, you could have as many processes as you wanted, all
listening on different IP addresses.

terry-...@glaver.org

unread,
Oct 13, 2017, 11:46:57 PM10/13/17
to
On Friday, October 13, 2017 at 3:10:34 AM UTC-4, Johnny Billquist wrote:
> Well, I can answer that one too. Owner is XX2247 LLC. The man behind
> that is Dave Carroll. He do not have any plans, as the original
> agreement between DEC and Mentec have clauses giving DEC a degree of
> control which limits what Mentec could do. That agreement is still in
> effect, but now it's HP and XX2247. And since HP have no clue, it's
> pretty much impossible to change that agreement, so it's stuck in limbo.
> Until someone can get HP to sign a new paper that is. After that, I
> think it's fair to say that it would be nice to get people to legally
> run these systems finally. I do not officially speak for XX2247, but I'm
> sortof involved.

Well, I have a RSTS/E source license (real source, not listings) and the hardware and actual license document in my basement.

2_SERVER::$ unzip -v RSTS_V10_1_SOURCE.ZIP;1
Archive: DKA0:[SPECIAL.DIGITAL]RSTS_V10_1_SOURCE.ZIP;1
Length Method Size Ratio Date Time CRC-32 Name
-------- ------ ------- ----- ---- ---- ------ ----
30229572 Defl:N 10715555 65% 11-24-93 07:13 f98ac1a5 rsts_v10_1_source.tap
-------- ------- --- -------
30229572 10715555 65% 1 file

Should the rightsholder(s) ever agree to allow distribution, or a DMCA
exemption for obsolete software be made permanent, a lot of stuff will
come out of the woodwork into the light of day again.

terry-...@glaver.org

unread,
Oct 13, 2017, 11:51:21 PM10/13/17
to
On Wednesday, October 11, 2017 at 9:45:06 PM UTC-4, Kerry Main wrote:
> Course, outside of the DEFCON stuff, I have never heard on any system
> running Finger on a VMS system.

2_SERVER::$ finger
SERVER DS10 616 MHz, VMS V8.4, Fri, 13-Oct-2017 23:48, 1 User, 0 Batch
Uptime 10 07:47, since Tue, 3-Oct-2017 16:00, Load: 0.00 0.00 0.00

PID Username Program Term Login CPU Location TT Type
00006233 TERRY $ NTY7: 03:56 0:08 bedroom VT3xx
0000B963 TERRY Finger NTY8: 03:26 0:07 office VT3xx

That system is connected to the Internet, but doesn't offer Finger service
outside the LAN. The software is DECUS Finger, of which I was the last main-
tainer. It supports DECnet, BITNET (with Jnet), and TCP/IP (with all of the
TCP stacks available as of that time).

David Froble

unread,
Oct 14, 2017, 12:08:08 AM10/14/17
to
Or add the task to a queue ..

Chris

unread,
Oct 14, 2017, 10:58:16 AM10/14/17
to
On 10/13/17 23:45, Stephen Hoffman wrote:

>
> Code that has no associated process context. OpenVMS and other systems
> can and do have inner-mode code that executes, and with no associated
> process context. This situation is entirely normal and expected for some
> of the code that executes on OpenVMS systems. This design is also part
> of a typical implementation and experience and trade-off that arises
> when designing most any kernel, and with the ever-present choices and
> trade-offs among the implementation choices, too. There's no right
> answer, and no single best design. Going into and out of process context
> or of swapping among process contexts can be slow. Yes, seL4 and
> Dragonfly BSD have gotten better about context switches, and system
> hardware is faster, too, but nobody really likes the overhead of the
> translation buffer and memory cache flushes that can arise with these
> operations. Various kernels — including OpenVMS — try to avoid
> unnecessary process context switches or unnecessary mode changes in
> performance-critical code paths. But again, OpenVMS does not have all of
> its code executing with an associated process context.

My argument was that from a top level OS point of view, there is a set
of tasks or processes, working set, whatever, managed by the scheduler
and apart from interrupt code, that's all there is. There may be code,
libraries, internal functions etc, but it doesn't run in isolation. It's
controlled, called, whatever from those top level processes. That's
why I was suggesting that everything, even indirectly, has a process
context.

>
> There's a write-up from a few years ago, around how long the kernel and
> the drivers and the processor and network hardware can dally, before
> there's packets getting dropped:
>
> https://lwn.net/Articles/629155/

Thanks.

>
> IEEE 802.3bs efforts around 200 GbE wired and 400 GbE optical standards
> are seemingly headed for approval later this year, not that OpenVMS is
> known for support for faster NICs, and we'll learn about the performance
> of the VSI TCPIP stack as that becomes available to customers over the
> next year or two.
> http://www.vmssoftware.com/pdfs/VSI_Roadmap_20170925.pdf
>
>

I will be interested to see how closely the network stack is in terms of
integration, how much of it is at kernel level etc. Whether all the
usual utilities are there at command line level.

>
> Yes, because the industry and the code and the tools we have all work so
> wonderfully well.

Right :-), but they actually do in the right hands. Attention to detail
is everything, like so many things in life. Sharp tools need skilled
hands.

>
> The older folks around the comp.os.vms newsgroup will undoubtedly
> remember the debates that raged around the move from the commonplace
> usage of assembler to the common usage of 3GL/HLL tools, certainly.
> Debates that included discussions of all the wasted performance that HLL
> code could entail, for instance. Times and tools change. Sometimes
> things change too fast. Sometimes not fast enough. And there's always
> legacy code around. And never enough budget. Vendors appear and vendors
> vaporize. Etc. But then I'd much rather having folks trying new and
> different and sometimes wacky stuff than not, too. I'd much rather work
> in C than assembler, too. Rust? Donno yet. That's not yet an option on
> OpenVMS, but does fix some of the more annoying limitations and hazards
> of C.
>
>

Well, i'm older as well, with wrinkles to prove it, but started
programming in assembler, coming from a hardware background. It
does take a lot of effort and use to become proficient in any
language and you get rusty with non use. I'm quite happy with C,
close to the metal etc, but only use a subset for clarity
and to make it easy for others coming later to understand,
something many programmers seem to forget.

Thanks for an interesting discussion. Years since I used VMS in
anger, but still track it's progress. I wonder why ?...

Regards,

Chris




Chris

unread,
Oct 14, 2017, 11:30:22 AM10/14/17
to
On 10/14/17 00:07, Arne Vajhøj wrote:

>
> I can not follow the logic. It is usually a lot easier
> to prevent code coming in via a high level script language
> web application that some low level compiled language web
> application.

Don't understand why that should be the case ?. Never programmed
php, but if it has facilities for running scripts, it's a
wide open door for hackers.

My rational for cgi, using a none X86 arch machine, was that
any hacker would need to disassemble the binary to understand
how it works. That rules out script kiddies and would need a
hacker familiar with the machine assembler. How many of those
are there that would also be motivated to break the code ?. NSA
perhaps, but the average hacker ?. Also, the code encrypts
and decrypts certain data on the fly, clearing buffers after
use, just to make it a bit more difficult. That is just
one plank in an overall security set of ideas.

Ok, the whole thing was done as an exercise, out of interest,
with no real commercial application at all, but isn't that
what some of us do ?. Firewalling and security are an interest
area here.

> I guess YMMV.
>
> But I find it difficult to see why all those *rejected* requests
> should be seen as a the language being bad.
>
> Arne

I don't think it does, but it does show that hackers assume
that some website owners are careless enough to leave
default named config files in default locations. Even the best
language or system is no defense against stupidity or ignorance.

Don't blame the tools etc, but the user...

Regards,

Chris



Dennis Boone

unread,
Oct 14, 2017, 2:30:29 PM10/14/17
to
> But those commands run as someone. Dennis mentioned Primos. I don't
> remember ever running commands without loggin in, but then, you had the
> console. You didn't log in on it but it was connected to the system as
> a user with elevated privileges. (anybody here ever hear about someone
> calling in claiming to be a Prime CE and having the operator switch the
> console to remote? :-) I am sure any connection that accepts commands
> is technically logged in as some default user and not just running in
> open space. The question then becomes who is that user and what level
> of privileges does it have.

For Primos, you had both an associated line, and possibly an associated
user identity. When logged out, those few commands (LOGIN, DROPDTR,
DELAY, USRASR, DATE, etc.) didn't care _who_ you were, just _where_
you were, and had no associated user identity.

The console was a different case. It _was_ logged in, as SYSTEM.
The remote console was just serial port hacks, you were still user
1, SYSTEM.

VM/CMS allowed a few commands while logged out also. LOGIN and DIAL
come to mind, there may have been others.

I can't speak to the -10 osen and other systems in detail.

De

Stephen Hoffman

unread,
Oct 14, 2017, 2:46:19 PM10/14/17
to
On 2017-10-14 15:30:20 +0000, Chris said:

> My rational for cgi, using a none X86 arch machine, was that any hacker
> would need to disassemble the binary to understand how it works. That
> rules out script kiddies and would need a
> hacker familiar with the machine assembler. How many of those are there
> that would also be motivated to break the code ?. NSA perhaps, but the
> average hacker ?

One of the OpenVMS-related discussion forums was overrun with folks
investigating an OpenVMS Alpha executable a while back, as that was a
part of a capture-the-flag event. For more than a few, it was clearly
the first OpenVMS Alpha image they'd ever encountered, but a number of
the folks were very effectively reversing its behaviors looking for the
mistakes and vulnerabilities within the tool.

Then there's that DEC shipped a disassembler for Alpha code as part of
OpenVMS Alpha, too:

srm_check -verbose -dump target.exe

That's not the only tool around, either.

> Even the best language or system is no defense against stupidity or ignorance.
>
> Don't blame the tools etc, but the user...

Unfortunately and all too often, that "blame the user" is also the
excuse that folks will use to avoid reviewing or considering their own
assumptions, their own tools, and their own continued use of same.
And we continue to deal with the results of that. That whether we're
discussing implications of "the most secure operating system on the
planet" or other utterly silly statements, or if we're failing to
account for the ample evidence that users can and will make mistakes,
that developers will continue to introduce bugs and vulnerabilities,
and that the younger folks and the newer approaches and tools can be
much smarter than the older folks give them credit for. Among other
implicit and willful blindnesses.

Stephen Hoffman

unread,
Oct 14, 2017, 2:55:11 PM10/14/17
to
On 2017-10-14 04:08:06 +0000, David Froble said:

...
> Or add the task to a queue ..

Device driver fork processes are queued. I/O request packets are
queued, too. The kernel uses queues in other places, too. Folks'd
use different data structures in a few of those places now,
particularly around cases were larger scales are required. As for
one of the other common queues on OpenVMS, the OpenVMS queue manager
would require the driver make a trip from kernel and into an ACP or a
user process, and from there a submission into the queue manager, and
eventually a trip back either directly or via a process or ACP with the
results of the request ACPs are pretty good at this sort of thing,
given that one of the key purposes of an ACP is to allow kernel-mode
code to access outer-mode and particularly user-mode functions; to
access APIs that are not directly callable from kernel-mode.

Kerry Main

unread,
Oct 14, 2017, 3:15:15 PM10/14/17
to comp.os.vms to email gateway
Well, I guess there is a first time for everything...

😊


Regards,

Kerry Main
Kerry dot main at starkgaming dot com




David Froble

unread,
Oct 14, 2017, 8:26:36 PM10/14/17
to
I've mentioned it before. There are many diverse things that have been done,
and are being done, on VMS. Don't think that everyone is using the OS as you are.

Kerry Main

unread,
Oct 14, 2017, 9:00:15 PM10/14/17
to comp.os.vms to email gateway
Yeah, you are right - I only have 35+ years of working on / supporting Customer OpenVMS systems all over the globe.

Been an OpenVMS Ambassador since 1981 ..

Btw, I never said no one runs finger - I only stated that in all the time I have been working on OpenVMS systems, I have never seen any Customer running Finger. It’s a Unix utility from the 70's that is off by default on all OpenVMS TCPIP stacks.

(Until the reference in this thread)

Arne Vajhøj

unread,
Oct 14, 2017, 11:28:53 PM10/14/17
to
On 10/14/2017 11:30 AM, Chris wrote:
> On 10/14/17 00:07, Arne Vajhøj wrote:
>> I can not follow the logic. It is usually a lot easier
>> to prevent code coming in via a high level script language
>> web application that some low level compiled language web
>> application.
>
> Don't understand why that should be the case ?.

Such languages do not suffer from buffer overruns.

Usually features is easily turned on/off via simple configuration files.

> Never programmed
> php, but if it has facilities for running scripts, it's a
> wide open door for hackers.

????

Practically all languages allows for running stuff.

PHP has include/require/include_once/require_once, C got
system, anything on VMS has LIB$SPAWN etc.etc..

Running stuff that you don't trust is not wise.

But the code doing so does not write itself. Not in C and
not in PHP.

> My rational for cgi, using a none X86 arch machine, was that
> any hacker would need to disassemble the binary to understand
> how it works. That rules out script kiddies and would need a
> hacker familiar with the machine assembler. How many of those
> are there that would also be motivated to break the code ?. NSA
> perhaps, but the average hacker ?.

If the hackers has access to the executable then they are already
on the system.

No need to figure out how that script works.

> Also, the code encrypts
> and decrypts certain data on the fly, clearing buffers after
> use, just to make it a bit more difficult. That is just
> one plank in an overall security set of ideas.

That approach does make it a little bit harder to recover
passwords within the binary.

But somewhat a corner case.

>> But I find it difficult to see why all those *rejected* requests
>> should be seen as a the language being bad.
>
> I don't think it does, but it does show that hackers assume
> that some website owners are careless enough to leave
> default named config files in default locations.
That should not be a problem (in normal cases).

A config PHP file just sets some variables to values.

When included in a another PHP file those variables can
be used to do stuff.

But if called directly, then it does nothing. And the
caller can not see the variables.

Problems only arise if:
* config files does not have .php extension
* config files does have .php extension, but the web server
serving the request does not have PHP installed
in which case the config file is not executed but retrieved
by caller.

Those requests were probably fishing after the second.

And if someone wonder why have PHP application if web server
does not have PHP installed, then it can happen that:
* people had installed PHP, installed the web app and
then deinstalled PHP
* people have multiple web servers serving the same
directory tree - one with PHP and one without [serving
same directory tree by multiple servers is *very*
dangerous!]

Arne
It is loading more messages.
0 new messages