On 2013-03-07 12:45, Jordi Guillaumes i Pons wrote:
Al 07/03/13 00:59, En/na Johnny Billquist ha escrit:
I hope you are aware of the fact that telnet by default is not 8-bit
clean. :-)
Well, sort of. The same xterm configuration displays (and inputs) 8 bit
characters if I telnet to a linux box...
That is probably because at connection time, telnets negotiate the capabilities between them. You can get very different behavior depending on what you have on each side.
I think it is related to the usage of UTF-8 in the unix machine... I
have reconfigured my ubuntu laptop to use ISO-8859-15 and it now _seems_
to work.
Ah. That is another issue. If your terminal (xterm in this case) is configured to use UTF-8, then you will not work well against a machine that do not use UTF-8 (it's a mess).
Johnny
Cory Smelosky <b4 at gewt.net> writes:
On 6 Mar 2013, at 21:48, "Brian Schenkenberger, VAXman-" =
<system at TMESIS.COM> wrote:
"Jerome H. Fine" <jhfinedp3k at compsys.to> writes:
=20
{...snip...}
Seriously, has anyone ever successfully developed a virus for
a VMS system? I think I heard that there was a yearly contest
to see if anyone could compromise a VMS system and it failed
every year.
=20
A few (2-3) years ago, there was a reported security elevation exploit =
that
involves a stupid buffer contamination exploit in =
SMG$READ_COMPOSED_LINE and
any VMS utility that employed it and that was installed with =
privileges. It
turned out that the INSTALL utility could be exploited. It was NOT =
simple
to do but it could be done. I implemented a weaponized PoC to exploit =
the
security vulnerabity. It was, happily, quickly addressed. =20
=20
There was also another exploit wherein one could send, via VMS mail, =
the
equivalent of an attachment using /FOREIGN. If the attachment was =
created
with SUBMIT-ON-CLOSE and the file was read by a privileged user, all =
bets
were off. Again, this was quickly subdued before it became a =
widespread
exploit. That, IIRC, was about a decade ago.
=20
Not a bad record at one vulnerability per decade. ;) The only real =
success
stories of infiltrating VMS all stemmed from social engineering and =
not, to
my knowledge, from security holes in the OS.
I was recently watching a DEFCON talk about breaking in to VMS=85no =
remote vulnerabilities were found. They all required human stupidity or =
an existing account.
http://www.youtube.com/watch?v=3DXf7gVma6_3g
The vulnerability I spoke to WRT the SMG$READ_COMPOSED_LINE is discussed
in this video; however, these VMS neophytes (and I still believe that the
fellow discussing the SMG$ issue was given information about this from a
disgruntled VMS engineer as he clearly does NOT know what he is speaking
about) were tutored by others. The nonsense about using a logical name
still makes me spew a mouthful of coffee, assuming I'm drinking it, upon
my screen and keyboard when I watch that video you've linked. To exploit
the security hole (now patched) required self-modifying Alpha code. It's
not very likely that these guys had the wherewithal to accomplish such a
feat with their neanderthal approach to the subject they presented.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
Al 07/03/13 00:59, En/na Johnny Billquist ha escrit:
I hope you are aware of the fact that telnet by default is not 8-bit clean. :-)
Well, sort of. The same xterm configuration displays (and inputs) 8 bit characters if I telnet to a linux box...
I think it is related to the usage of UTF-8 in the unix machine... I have reconfigured my ubuntu laptop to use ISO-8859-15 and it now _seems_ to work.
On 6 Mar 2013, at 21:48, "Brian Schenkenberger, VAXman-" <system at TMESIS.COM> wrote:
"Jerome H. Fine" <jhfinedp3k at compsys.to> writes:
{...snip...}
Seriously, has anyone ever successfully developed a virus for
a VMS system? I think I heard that there was a yearly contest
to see if anyone could compromise a VMS system and it failed
every year.
A few (2-3) years ago, there was a reported security elevation exploit that
involves a stupid buffer contamination exploit in SMG$READ_COMPOSED_LINE and
any VMS utility that employed it and that was installed with privileges. It
turned out that the INSTALL utility could be exploited. It was NOT simple
to do but it could be done. I implemented a weaponized PoC to exploit the
security vulnerabity. It was, happily, quickly addressed.
There was also another exploit wherein one could send, via VMS mail, the
equivalent of an attachment using /FOREIGN. If the attachment was created
with SUBMIT-ON-CLOSE and the file was read by a privileged user, all bets
were off. Again, this was quickly subdued before it became a widespread
exploit. That, IIRC, was about a decade ago.
Not a bad record at one vulnerability per decade. ;) The only real success
stories of infiltrating VMS all stemmed from social engineering and not, to
my knowledge, from security holes in the OS.
I was recently watching a DEFCON talk about breaking in to VMS no remote vulnerabilities were found. They all required human stupidity or an existing account.
http://www.youtube.com/watch?v=Xf7gVma6_3g
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
"Jerome H. Fine" <jhfinedp3k at compsys.to> writes:
{...snip...}
Seriously, has anyone ever successfully developed a virus for
a VMS system? I think I heard that there was a yearly contest
to see if anyone could compromise a VMS system and it failed
every year.
A few (2-3) years ago, there was a reported security elevation exploit that
involves a stupid buffer contamination exploit in SMG$READ_COMPOSED_LINE and
any VMS utility that employed it and that was installed with privileges. It
turned out that the INSTALL utility could be exploited. It was NOT simple
to do but it could be done. I implemented a weaponized PoC to exploit the
security vulnerabity. It was, happily, quickly addressed.
There was also another exploit wherein one could send, via VMS mail, the
equivalent of an attachment using /FOREIGN. If the attachment was created
with SUBMIT-ON-CLOSE and the file was read by a privileged user, all bets
were off. Again, this was quickly subdued before it became a widespread
exploit. That, IIRC, was about a decade ago.
Not a bad record at one vulnerability per decade. ;) The only real success
stories of infiltrating VMS all stemmed from social engineering and not, to
my knowledge, from security holes in the OS.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
On 2013-03-07 00:49, Jordi Guillaumes i Pons wrote:
Telnet (either using -e telnet XXXX or from a local shell).
Oh, and I'm sure it is a keyboard problem and not a display problem. I can see the national characters on screen when I TYPE a file which contain those...
Jordi Guillaumes i Pons
Barcelona - Catalunya - Europa
El 07/03/2013, a les 0:39, Johnny Billquist <bqt at softjar.se> va escriure:
How do you connect to the VMS system?
I hope you are aware of the fact that telnet by default is not 8-bit clean. :-)
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Telnet (either using -e telnet XXXX or from a local shell).
Oh, and I'm sure it is a keyboard problem and not a display problem. I can see the national characters on screen when I TYPE a file which contain those...
Jordi Guillaumes i Pons
Barcelona - Catalunya - Europa
El 07/03/2013, a les 0:39, Johnny Billquist <bqt at softjar.se> va escriure:
How do you connect to the VMS system?
On 2013-03-06 23:46, Jordi Guillaumes i Pons wrote:
Hello list,
I have been following this discussion about terminal emulators and I have decided to give xterm a(nother) try. I have built an .XResources file with this content:
XTerm.vt100.decTerminalID: 220
XTerm.vt100.allowScrollLock: True
XTerm.vt100.appkeypadDefault: True
XTerm.vt100.backarrowKey: False
XTerm.vt100.c132: True
XTerm.vt100.cursorBlink: True
XTerm.vt100.fontWarnings: 1
XTerm.vt100.geometry: 80x25
XTerm.vt100.faceName: lucida console
XTerm.vt100.faceSize: 12.0
XTerm.vt100.utf8: false
XTerm.vt100.locale: ISO8859-1
XTerm.vt100.keyboardType: vt220
XTerm.vt100.keyboardDialect: Z
(The "Z" keyboard dialect corresponds to the spanish DEC keyboard)
Now it seems to work quite well displaying stuff, and the keypad and the rest of application keys work, BUT the 8 bit spanish/catalan symbols DO NOT. What is curious about this is if I connect to a linux/OSX system the 8-bit stuff works (characters like , , , and vowels with tilde). But as soon as I connect to an VMS machine it DOES not. It seems to drop the highest bit.
The .Xresources configuration is the final one I worked on (the keyboardType and keyboardDialect are late additions, just to try to fix it). I have not been able to make it work with the local keys...
Any idea?
How do you connect to the VMS system?
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On 2013-03-06 13:52, Brian Schenkenberger, VAXman- wrote:
Johnny Billquist <bqt at softjar.se> writes:
{...snip...}
Good question. I just let it use the default font, whatever that is.
Also, I just looked and noticed that Ctrl-Right Mouse shows an option
for enabling double sized characters. Do you have that, and is it enabled?
CTRL-MB3 ;) shows that they are selected. Same here too with default font.
Ok. The only thing I can think of is missing fonts then, and unfortunately I don't know which font xterm tries to use.
I can try looking at the sources of xterm later, but it would appear your setup in most ways match mine, yet we seem to get very different results.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On 6 Mar 2013, at 16:46, "Jerome H. Fine" <jhfinedp3k at compsys.to> wrote:
Dave McGuire wrote:
On 03/06/2013 07:29 AM, Jerome H. Fine wrote:
I've mentioned this to one or two folks here privately, but now that
it has come up...My mother is a journalist with Associated Press, and
she recently took a new assignment in a different city. Their office
has a VAX-4000 running VMS, handling some sort of database. They love
it, and they have no plans to migrate away from it.
It would be appreciated if a few interesting aspects concerning
the system were shared so we could understand how such a
mature system manages to compete.
I suspect it's not trying to "compete", at least not any more than,
say, the desks (not the desktops, but the DESKS) in the offices, etc.
It's an appliance; it sits there and does its job. There's no valid
reason to change it.
I should have said "continue to perform at more than the required
level of reliability, performance, availability and security" as opposed
to "compete".
My understanding is that a VMS system which has sufficient CPU
power and disk space will continue to out-perform any windows
based system.
The only problem is that if the number of transactions per second
increases to the point that the response is too long, then something
has to be done.
There's an odd consumerist attitude that goes something like "oh, the
manufacturer has introduced a new model, this one must somehow suck now,
I'd better replace it!"...That attitude is common in the worlds of
computers and cars, but not much else. If Great Neck (a common-in-USA
manufacturer of cheap-but-usable hand tools) introduces a new model of
hammer, I'm not going to throw my old one (probably twenty years old)
and rush out to buy the new one. That would be stupid...and it's just
as stupid with computers and cars.
What a "refreshing" (my you are logical - but then I guess I have
been told I am as well) attitude. Of course, that doesn't work
for a consumer society, but maybe it would if the focus on
having a satisfying toy rather than the newest toy was important.
I'm pretty sure I'm preaching to the choir here...at least I really
hope I am. ;)
Why do you think I asked the question that way?
(a) When was the system first installed?
I have no idea. She says she thinks it was a 4000-500, which would
put it in the mid-1990s.
That sounds about right. The high end VAX systems were
the final DEC attempt to continue the obsolete marking model.
The software and hardware were the best. But the Alpha was
just too late.
(b) Approximately how long is the up-time between re-boots?
Again I have no idea. (this is my mother's place of employment, 1200mi
from here, not mine) Let's put it this way, though...it's likely that
this machine is running VMS, and it's not at all unusual for VMS systems
to have uptimes in the 5+ year range. If it didn't get those sorts of
uptimes, it probably would've annoyed someone and gotten replaced by now.
My joke with anyone who was not familiar with the VAX / VMS systems
was that the uptime measurement unit was DECADES. The uptime with
Clusters was in CENTURIES. Of course, the latter joke was considered
so impossible that it was useless to even attempt to explain.
(c) Do they have any virus problems?
(d) Have they ever been hacked into?
ROFL!!! I haven't had a laugh this good on a long time. ;)
GLAD to be of service. I know that early VMS software
tended to have a few glitches, but by the early 1990s, DEC
had managed to plug the holes. Of course, each VMS release
was built directly on the shoulders of the previous version
which had the advantage of decades of testing. Somehow,
a particular company whose name started with M forgot that.
Seriously, has anyone ever successfully developed a virus for
a VMS system? I think I heard that there was a yearly contest
to see if anyone could compromise a VMS system and it failed
every year.
Once in the '80s I believe. It wasn't very destructive and it spread through human stupidity I believe.
A denial of service attack is a different problem. Did DEC ever
find a work around for that problem?
Other information such as the physical details would also be
interesting along with the number of users. Anything else
your mother felt willing to share would provide the list
members with good hard information.
She's pretty busy in her new assignment, but I'm sure she can do some
digging. I'd love to find out more myself.
It seems so unreasonable that such incredible software as
VMS and hardware such as the VAX and Alpha were unable
to compete with other products. But marketing is also needed
at some level. DEC's marketing needed to focus on the reason
why they were so superior and why in the long run they were
probably more cost effective.
For that, Ken Olsen seems to have been the wrong person.
Jerome Fine
