Discussion:
Linux as bad as windows, CIA vault 7 hacks exposed
Add Reply
u***@gmail.com
2017-06-22 11:46:46 UTC
Reply
Permalink
Raw Message
so not only does the cia control windows hacking, but linux also.
OpenVMS not included because malware doesn't work on it.


Simon Clubley
2017-06-22 12:44:32 UTC
Reply
Permalink
Raw Message
Post by u***@gmail.com
so not only does the cia control windows hacking, but linux also.
And every other operating system in existence.
Post by u***@gmail.com
OpenVMS not included because malware doesn't work on it.
Yes it bloody well does (as the DEFCON researchers proved and as you
have been told multiple times) and VMS actually has some nice features
from an attacker's point of view which means you may not even have to
faff around with trying to get your shellcode to run from the stack
if you are trying to compromise VMS from a logged in session.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Bill Gunshannon
2017-06-22 12:55:22 UTC
Reply
Permalink
Raw Message
Post by u***@gmail.com
so not only does the cia control windows hacking, but linux also.
OpenVMS not included because malware doesn't work on it.
http://youtu.be/w1-nmA5My7U
No, actually OpenVMS not included because it is irrelevant.

bill
Scott Dorsey
2017-06-22 12:59:08 UTC
Reply
Permalink
Raw Message
Post by u***@gmail.com
so not only does the cia control windows hacking, but linux also.
OpenVMS not included because malware doesn't work on it.
http://youtu.be/w1-nmA5My7U
Interestingly, just about every vulnerability described here is in some part
of linux that I normally disable or tailor off. systemd is making this much
more difficult, but the more modular the operating system is, the more easily
you can shut things off you don't need. Code that you aren't running is code
that you don't have to worry about vulnerabilities in.

Unfortunately VMS is kind of deficient in the modularity department, although
I'll admit things have improved greatly since 4.7 in that regard.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
Arne Vajhøj
2017-06-22 16:17:26 UTC
Reply
Permalink
Raw Message
Post by Scott Dorsey
Post by u***@gmail.com
so not only does the cia control windows hacking, but linux also.
OpenVMS not included because malware doesn't work on it.
http://youtu.be/w1-nmA5My7U
Interestingly, just about every vulnerability described here is in some part
of linux that I normally disable or tailor off. systemd is making this much
more difficult, but the more modular the operating system is, the more easily
you can shut things off you don't need. Code that you aren't running is code
that you don't have to worry about vulnerabilities in.
Yes.

And with the explosion in code sizes this has become essential.

The code base for a complete large Linux distro must be in
the 400-500 MLOC range today.

Arne
Stephen Hoffman
2017-06-22 13:43:32 UTC
Reply
Permalink
Raw Message
Post by u***@gmail.com
so not only does the cia control windows hacking, but linux also.
OpenVMS not included because malware doesn't work on it.
If an entity with the resources of a nation-state intelligence agency
looks into OpenVMS, there will be vulnerabilities found.

There are already vulnerabilities known, though you would clearly only
deign to notice those vulnerabilities if it were another platform
suffering those and not OpenVMS.

Like Vault 7, we won't hear of vulnerabilities gathered until knowledge
of the leaks, either through use or through a deliberate leak, or if
the vulnerabilities are reported to VSI and we get patches.

Those patches do not happen quickly, as I've reported a remote command
execution in OpenVMS over a year ago. You'd be highlighting that, if
it were another platform.

But given common practices on many OpenVMS systems, why even expose a
vulnerability when telnet, ftp and SCS all leak data?

If you want to help OpenVMS, please learn more about security and about
modern attacks and vulnerabilities and security defenses, learn where
OpenVMS works and where it doesn't, and learn why security is never the
top criteria in a server purchase. The server first has to have the
software to do the job required — there's no point in purchasing a
server just to be secure — and the server and the software and the
staff training and support and the application and any required porting
all has to be affordable.
--
Pure Personal Opinion | HoffmanLabs LLC
Simon Clubley
2017-06-22 18:15:20 UTC
Reply
Permalink
Raw Message
Post by Stephen Hoffman
Like Vault 7, we won't hear of vulnerabilities gathered until knowledge
of the leaks, either through use or through a deliberate leak, or if
the vulnerabilities are reported to VSI and we get patches.
Those patches do not happen quickly, as I've reported a remote command
execution in OpenVMS over a year ago.
Has it been determined what the CVSS score is for this vulnerability ?

Are there any mitigating circumstances which would reduce its impact
on most VMS sites ?

I'm assuming from the wording that it is either in VMS or layered
product software shipped by HP and/or VSI and not some unrelated
third party application.

If this is a vulnerability with a high CVSS score and no real
mitigating circumstances, then I urge you to push the vendor to
release a patch and then to release the details under the
responsible disclosure protocols.

You have given them a year, which is about 9 months longer than
a normal security researcher would give them and if you can find
this then so can others and their intentions may not be as benign
as yours are.

If this is a high impact vulnerability, then the security of all VMS
systems is impacted if the vendor is allowed to drag out the release
of any patch and people are not warned if the vendor refuses to fix
it for some reason.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Michael Moroney
2017-06-22 15:08:49 UTC
Reply
Permalink
Raw Message
Post by u***@gmail.com
so not only does the cia control windows hacking, but linux also.
OpenVMS not included because malware doesn't work on it.
http://youtu.be/w1-nmA5My7U
Are you sure? With ancient TCPIP I'm sure that a nation-state
intelligence agency could have found a few holes. The question
is whether they needed to look for them, and if they did, are
they in what was released?
Simon Clubley
2017-06-22 18:28:19 UTC
Reply
Permalink
Raw Message
Post by Michael Moroney
Post by u***@gmail.com
so not only does the cia control windows hacking, but linux also.
OpenVMS not included because malware doesn't work on it.
http://youtu.be/w1-nmA5My7U
Are you sure? With ancient TCPIP I'm sure that a nation-state
intelligence agency could have found a few holes. The question
is whether they needed to look for them, and if they did, are
they in what was released?
I hope you are not implying that HP or VSI have received some kind
of forced compliance with the NSA notification (either via a NSL or
some other mechanism) that requires HP or VSI to hand over any VMS
security vulnerabilities they receive to the NSA... :-)

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Michael Moroney
2017-06-23 05:36:37 UTC
Reply
Permalink
Raw Message
Post by Simon Clubley
Post by Michael Moroney
Post by u***@gmail.com
so not only does the cia control windows hacking, but linux also.
OpenVMS not included because malware doesn't work on it.
http://youtu.be/w1-nmA5My7U
Are you sure? With ancient TCPIP I'm sure that a nation-state
intelligence agency could have found a few holes. The question
is whether they needed to look for them, and if they did, are
they in what was released?
I hope you are not implying that HP or VSI have received some kind
of forced compliance with the NSA notification (either via a NSL or
some other mechanism) that requires HP or VSI to hand over any VMS
security vulnerabilities they receive to the NSA... :-)
No, all I am saying is if the NSA wanted in on a VMS system for any
reason, I bet they could get in, and most likely through an old TCP/IP
exploit long patched elsewhere. They (and other countries' equivalent)
have some very good people.

Of course, if they have no need to get in anywhere, then they
probably won't have an exploit among the ones leaked.
Arne Vajhøj
2017-06-22 15:22:29 UTC
Reply
Permalink
Raw Message
Post by u***@gmail.com
so not only does the cia control windows hacking, but linux also.
OpenVMS not included because malware doesn't work on it.
You do not consider the WANK worm to be malware??

Arne
Kerry Main
2017-06-24 12:39:56 UTC
Reply
Permalink
Raw Message
-----Original Message-----
Vajhøj via Info-vax
Sent: June 22, 2017 11:22 AM
Subject: Re: [Info-vax] Linux as bad as windows, CIA vault 7 hacks
exposed
Post by u***@gmail.com
so not only does the cia control windows hacking, but linux also.
OpenVMS not included because malware doesn't work on it.
You do not consider the WANK worm to be malware??
Arne
Like all platforms, OpenVMS definitely needs work in the security area.

Having stated this, I find it interesting that those who wish to detract
OpenVMS's capabilities has to refer to a 1989 vulnerability like WANK.

<https://en.wikipedia.org/wiki/WANK_(computer_worm)>
"The WANK Worm was a computer worm that attacked DEC VMS computers in
1989 over the DECnet. It was written in DIGITAL Command Language"

Kind of like talking about Windows security and referring back to
Windows 95 vulnerabilities as an example.

Again, yes, like all platforms, OpenVMS does need work in the area of
security, but surely references from 1989 (or in the case of recent
Defcon OpenVMS presentations, references to pre-1993) are not good
examples of why this is so.

Regards,

Kerry Main
Kerry dot main at starkgaming dot com
Simon Clubley
2017-06-24 19:46:03 UTC
Reply
Permalink
Raw Message
Post by Kerry Main
Like all platforms, OpenVMS definitely needs work in the security area.
Having stated this, I find it interesting that those who wish to detract
OpenVMS's capabilities has to refer to a 1989 vulnerability like WANK.
The SMG$ exploit was for current VMS versions.

There are apparently various unfixed issues in the TCP/IP stack.

Stephen has found a remote command execution vulnerability somewhere
but for obvious reasons has not yet made the details public.
Post by Kerry Main
<https://en.wikipedia.org/wiki/WANK_(computer_worm)>
"The WANK Worm was a computer worm that attacked DEC VMS computers in
1989 over the DECnet. It was written in DIGITAL Command Language"
Kind of like talking about Windows security and referring back to
Windows 95 vulnerabilities as an example.
It's interesting that you make that reference because VMS still has
design features common at that time which weaken VMS security in 2017.

For example:

Data-only memory such as the logicals and general buffers is executable.

There's no ASLR in VMS.

There's a common address space shared between DCL, non-privileged
programs and privileged systems utilities. The non-privileged program
can place shellcode at a known location and all you need to do is to
clobber the return address in the privileged program. There's no need
to goto the extra effort of trying to place your shellcode on the stack.
Post by Kerry Main
Again, yes, like all platforms, OpenVMS does need work in the area of
security, but surely references from 1989 (or in the case of recent
Defcon OpenVMS presentations, references to pre-1993) are not good
examples of why this is so.
Kerry, which DEFCON presentation are you thinking of ?

The SMG$ issue applied to the current VMS versions at that time.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Arne Vajhøj
2017-06-24 20:04:05 UTC
Reply
Permalink
Raw Message
Post by Kerry Main
Vajhøj via Info-vax
Post by u***@gmail.com
so not only does the cia control windows hacking, but linux also.
OpenVMS not included because malware doesn't work on it.
You do not consider the WANK worm to be malware??
Like all platforms, OpenVMS definitely needs work in the security area.
Having stated this, I find it interesting that those who wish to detract
OpenVMS's capabilities has to refer to a 1989 vulnerability like WANK.
Kind of like talking about Windows security and referring back to
Windows 95 vulnerabilities as an example.
Again, yes, like all platforms, OpenVMS does need work in the area of
security, but surely references from 1989 (or in the case of recent
Defcon OpenVMS presentations, references to pre-1993) are not good
examples of why this is so.
It proves that malware can work on VMS.

This particular vulnerability is of course fixed decades ago.

But has any changes been made to VMS since then that should
prevent all malware from running on VMS?

I don't think so.

Arne
Kerry Main
2017-06-25 01:09:08 UTC
Reply
Permalink
Raw Message
-----Original Message-----
Vajhøj via Info-vax
Sent: June 24, 2017 4:04 PM
Subject: Re: [Info-vax] Linux as bad as windows, CIA vault 7 hacks
exposed
Arne
Post by Kerry Main
Vajhøj via Info-vax
Post by u***@gmail.com
so not only does the cia control windows hacking, but linux also.
OpenVMS not included because malware doesn't work on it.
You do not consider the WANK worm to be malware??
Like all platforms, OpenVMS definitely needs work in the security area.
Having stated this, I find it interesting that those who wish to detract
OpenVMS's capabilities has to refer to a 1989 vulnerability like WANK.
Kind of like talking about Windows security and referring back to
Windows 95 vulnerabilities as an example.
Again, yes, like all platforms, OpenVMS does need work in the area of
security, but surely references from 1989 (or in the case of recent
Defcon OpenVMS presentations, references to pre-1993) are not good
examples of why this is so.
It proves that malware can work on VMS.
This particular vulnerability is of course fixed decades ago.
But has any changes been made to VMS since then that should
prevent all malware from running on VMS?
I don't think so.
Arne
Other than perhaps 95+% of all malware is targeted at Windows, Linux, Android, and/or IOS?

Again, I am not saying the OpenVMS platform is invulnerable, but for whatever the reason, I am not aware of any recent worms to impact OpenVMS in the last 15+ years.

Certainly willing to be corrected - any links or pointers?


Regards,

Kerry Main
Kerry dot main at starkgaming dot com
Arne Vajhøj
2017-06-25 01:44:56 UTC
Reply
Permalink
Raw Message
Post by Kerry Main
-----Original Message-----
Arne
Post by Kerry Main
Vajhøj via Info-vax
Post by u***@gmail.com
so not only does the cia control windows hacking, but linux also.
OpenVMS not included because malware doesn't work on it.
You do not consider the WANK worm to be malware??
Like all platforms, OpenVMS definitely needs work in the security area.
Having stated this, I find it interesting that those who wish to detract
OpenVMS's capabilities has to refer to a 1989 vulnerability like WANK.
Kind of like talking about Windows security and referring back to
Windows 95 vulnerabilities as an example.
Again, yes, like all platforms, OpenVMS does need work in the area of
security, but surely references from 1989 (or in the case of recent
Defcon OpenVMS presentations, references to pre-1993) are not good
examples of why this is so.
It proves that malware can work on VMS.
This particular vulnerability is of course fixed decades ago.
But has any changes been made to VMS since then that should
prevent all malware from running on VMS?
I don't think so.
Other than perhaps 95+% of all malware is targeted at Windows,
Linux, Android, and/or IOS?
Malware writers mostly targets the same platforms as legit software
producers - those platforms that are used.
Post by Kerry Main
Again, I am not saying the OpenVMS platform is invulnerable, but for
whatever the reason, I am not aware of any recent worms to impact
OpenVMS in the last 15+ years.
Certainly willing to be corrected - any links or pointers?
I have not heard about any malware in the wild on VMS the last 15 years.

I have not heard about any malware in the wild on DOS the last 15 years
either.

I would not conclude that DOS can not get malware based
on that observation.

Arne
Kerry Main
2017-06-25 02:24:51 UTC
Reply
Permalink
Raw Message
-----Original Message-----
Vajhøj via Info-vax
Sent: June 24, 2017 9:45 PM
Subject: Re: [Info-vax] Linux as bad as windows, CIA vault 7 hacks
exposed
Post by Kerry Main
-----Original Message-----
Arne
Of
Post by Kerry Main
Arne
Post by Kerry Main
Vajhøj via Info-vax
Post by u***@gmail.com
so not only does the cia control windows hacking, but linux also.
OpenVMS not included because malware doesn't work on it.
You do not consider the WANK worm to be malware??
Like all platforms, OpenVMS definitely needs work in the security
area.
Post by Kerry Main
Post by Kerry Main
Having stated this, I find it interesting that those who wish to detract
OpenVMS's capabilities has to refer to a 1989 vulnerability like
WANK.
Post by Kerry Main
Post by Kerry Main
Kind of like talking about Windows security and referring back to
Windows 95 vulnerabilities as an example.
Again, yes, like all platforms, OpenVMS does need work in the area
of
Post by Kerry Main
Post by Kerry Main
security, but surely references from 1989 (or in the case of recent
Defcon OpenVMS presentations, references to pre-1993) are not
good
Post by Kerry Main
Post by Kerry Main
examples of why this is so.
It proves that malware can work on VMS.
This particular vulnerability is of course fixed decades ago.
But has any changes been made to VMS since then that should
prevent all malware from running on VMS?
I don't think so.
Other than perhaps 95+% of all malware is targeted at Windows,
Linux, Android, and/or IOS?
Malware writers mostly targets the same platforms as legit software
producers - those platforms that are used.
Not really, most malware writers target "easy" platforms. These writers are very familiar with commodity OS's (Windows, Linux, Android, IOS etc.), so they target these as there is a lot of self-bragging and "cred" within the hacker community associated with writing something that impacts a large number of users and gets publicized in the press.

OpenVMS today runs in many stock exchanges, banks, manufacturing, power utilities (many SCAD), nuclear stations etc. If it was an easy target, hackers would certainly target OpenVMS as well.

That is not to say it is impossible, just harder and the script kiddie hackers prefer easy targets.

Course, the more serious hackers are a big concern for every platform.
Post by Kerry Main
Again, I am not saying the OpenVMS platform is invulnerable, but for
whatever the reason, I am not aware of any recent worms to impact
OpenVMS in the last 15+ years.
Certainly willing to be corrected - any links or pointers?
I have not heard about any malware in the wild on VMS the last 15 years.
I have not heard about any malware in the wild on DOS the last 15 years
either.
I would not conclude that DOS can not get malware based
on that observation.
Arne
I do not know of many DOS platforms today running stock exchanges such as Shanghai Stock exchange (they replaced HP-UX with OpenVMS/IA64 - some think may be the future replacement for NYSE as the global finance centre) or power utilities or big lotteries, or banks or manufacturing or ... if it was so easy to write malware for OpenVMS, why do we not see these in the press? Surely, a stock exchange or bank incident would be big news whereby the company would typically be forced by law to go public?

Again, no platform is 100% secure, and OpenVMS does need security enhancements but for whatever the reason, there has not been any significant OpenVMS based malware incidents in the press that I am aware of.

Regards,

Kerry Main
Kerry dot main at starkgaming dot com
Bill Gunshannon
2017-06-25 12:11:42 UTC
Reply
Permalink
Raw Message
Post by Arne Vajhøj
Post by Kerry Main
-----Original Message-----
Arne
Post by Kerry Main
Vajhøj via Info-vax
Post by u***@gmail.com
so not only does the cia control windows hacking, but linux also.
OpenVMS not included because malware doesn't work on it.
You do not consider the WANK worm to be malware??
Like all platforms, OpenVMS definitely needs work in the security area.
Having stated this, I find it interesting that those who wish to detract
OpenVMS's capabilities has to refer to a 1989 vulnerability like WANK.
Kind of like talking about Windows security and referring back to
Windows 95 vulnerabilities as an example.
Again, yes, like all platforms, OpenVMS does need work in the area of
security, but surely references from 1989 (or in the case of recent
Defcon OpenVMS presentations, references to pre-1993) are not good
examples of why this is so.
It proves that malware can work on VMS.
This particular vulnerability is of course fixed decades ago.
But has any changes been made to VMS since then that should
prevent all malware from running on VMS?
I don't think so.
Other than perhaps 95+% of all malware is targeted at Windows,
Linux, Android, and/or IOS?
Malware writers mostly targets the same platforms as legit software
producers - those platforms that are used.
Post by Kerry Main
Again, I am not saying the OpenVMS platform is invulnerable, but for
whatever the reason, I am not aware of any recent worms to impact
OpenVMS in the last 15+ years.
Certainly willing to be corrected - any links or pointers?
I have not heard about any malware in the wild on VMS the last 15 years.
I have not heard about any malware in the wild on DOS the last 15 years
either.
I would not conclude that DOS can not get malware based
on that observation.
I have never heard of malware on PRIMOS. And, yes, PRIMOS is still in
use. And then you have OS2200. How about QNX? OS-9000? Never try to
associate lack of publicly acknowledged attacks with security.

bill
Bill Gunshannon
2017-06-25 12:09:05 UTC
Reply
Permalink
Raw Message
Post by Kerry Main
-----Original Message-----
Vajhøj via Info-vax
Sent: June 24, 2017 4:04 PM
Subject: Re: [Info-vax] Linux as bad as windows, CIA vault 7 hacks
exposed
Arne
Post by Kerry Main
Vajhøj via Info-vax
Post by u***@gmail.com
so not only does the cia control windows hacking, but linux also.
OpenVMS not included because malware doesn't work on it.
You do not consider the WANK worm to be malware??
Like all platforms, OpenVMS definitely needs work in the security area.
Having stated this, I find it interesting that those who wish to detract
OpenVMS's capabilities has to refer to a 1989 vulnerability like WANK.
Kind of like talking about Windows security and referring back to
Windows 95 vulnerabilities as an example.
Again, yes, like all platforms, OpenVMS does need work in the area of
security, but surely references from 1989 (or in the case of recent
Defcon OpenVMS presentations, references to pre-1993) are not good
examples of why this is so.
It proves that malware can work on VMS.
This particular vulnerability is of course fixed decades ago.
But has any changes been made to VMS since then that should
prevent all malware from running on VMS?
I don't think so.
Arne
Other than perhaps 95+% of all malware is targeted at Windows, Linux, Android, and/or IOS?
Again, I am not saying the OpenVMS platform is invulnerable, but for whatever the reason, I am not aware of any recent worms to impact OpenVMS in the last 15+ years.
Certainly willing to be corrected - any links or pointers?
And, once again, do you really think it is because VMS is
invulnerable or is it much more likely it's because VMS is
irrelevant in the IT world.

bill
Kerry Main
2017-06-25 12:54:12 UTC
Reply
Permalink
Raw Message
-----Original Message-----
Gunshannon via Info-vax
Sent: June 25, 2017 8:09 AM
Subject: Re: [Info-vax] Linux as bad as windows, CIA vault 7 hacks
exposed
Post by Kerry Main
-----Original Message-----
Arne
Post by Kerry Main
Vajhøj via Info-vax
Sent: June 24, 2017 4:04 PM
Subject: Re: [Info-vax] Linux as bad as windows, CIA vault 7 hacks
exposed
Of
Post by Kerry Main
Arne
Post by Kerry Main
Vajhøj via Info-vax
Post by u***@gmail.com
so not only does the cia control windows hacking, but linux also.
OpenVMS not included because malware doesn't work on it.
You do not consider the WANK worm to be malware??
Like all platforms, OpenVMS definitely needs work in the security
area.
Post by Kerry Main
Post by Kerry Main
Having stated this, I find it interesting that those who wish to detract
OpenVMS's capabilities has to refer to a 1989 vulnerability like
WANK.
Post by Kerry Main
Post by Kerry Main
Kind of like talking about Windows security and referring back to
Windows 95 vulnerabilities as an example.
Again, yes, like all platforms, OpenVMS does need work in the area
of
Post by Kerry Main
Post by Kerry Main
security, but surely references from 1989 (or in the case of recent
Defcon OpenVMS presentations, references to pre-1993) are not
good
Post by Kerry Main
Post by Kerry Main
examples of why this is so.
It proves that malware can work on VMS.
This particular vulnerability is of course fixed decades ago.
But has any changes been made to VMS since then that should
prevent all malware from running on VMS?
I don't think so.
Arne
Other than perhaps 95+% of all malware is targeted at Windows, Linux,
Android, and/or IOS?
Post by Kerry Main
Again, I am not saying the OpenVMS platform is invulnerable, but for
whatever the reason, I am not aware of any recent worms to impact
OpenVMS in the last 15+ years.
Post by Kerry Main
Certainly willing to be corrected - any links or pointers?
And, once again, do you really think it is because VMS is
invulnerable or is it much more likely it's because VMS is
irrelevant in the IT world.
bill
Read my response - "> > Again, I am not saying the OpenVMS platform is invulnerable,"

Re: irrelevant .. ROTFL - tell that to all the stock exchanges, banks, insurance and financial institutions, retail, lotteries, Govt, power utilities, nuclear, ISP's, manufacturing (e.g. IBM, Intel), that one of their core platforms integral to their business is irrelevant. I am sure they will love to hear your opinion on this.

😊

Regards,

Kerry Main
Kerry dot main at starkgaming dot com
Scott Dorsey
2017-06-25 15:50:13 UTC
Reply
Permalink
Raw Message
Post by Arne Vajhøj
It proves that malware can work on VMS.
This particular vulnerability is of course fixed decades ago.
But has any changes been made to VMS since then that should
prevent all malware from running on VMS?
If anything, changes have been made to VMS since then which likely makes
vulnerabilities that can be exploited by new malware more frequent.

I claim that the number one cause of clear software vulnerabilities today is
the use of null-terminated strings, and until we get rid of the use of
C strings completely we will be having to worry about buffer overrun issues.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
u***@gmail.com
2017-06-26 11:29:05 UTC
Reply
Permalink
Raw Message
Post by Scott Dorsey
Post by Arne Vajhøj
It proves that malware can work on VMS.
This particular vulnerability is of course fixed decades ago.
But has any changes been made to VMS since then that should
prevent all malware from running on VMS?
If anything, changes have been made to VMS since then which likely makes
vulnerabilities that can be exploited by new malware more frequent.
I claim that the number one cause of clear software vulnerabilities today is
the use of null-terminated strings, and until we get rid of the use of
C strings completely we will be having to worry about buffer overrun issues.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
I would take that one step farther and get rid of the c language :)
Stephen Hoffman
2017-06-26 13:26:12 UTC
Reply
Permalink
Raw Message
Post by u***@gmail.com
I would take that one step farther and get rid of the c language :)
I'm sure everybody is willing and able to pay to have all that source
code rewritten in Rust, Go or some other newer language, and then
debugged and integrated and tested.
--
Pure Personal Opinion | HoffmanLabs LLC
Bill Gunshannon
2017-06-26 13:44:56 UTC
Reply
Permalink
Raw Message
Post by u***@gmail.com
Post by Scott Dorsey
Post by Arne Vajhøj
It proves that malware can work on VMS.
This particular vulnerability is of course fixed decades ago.
But has any changes been made to VMS since then that should
prevent all malware from running on VMS?
If anything, changes have been made to VMS since then which likely makes
vulnerabilities that can be exploited by new malware more frequent.
I claim that the number one cause of clear software vulnerabilities today is
the use of null-terminated strings, and until we get rid of the use of
C strings completely we will be having to worry about buffer overrun issues.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
I would take that one step farther and get rid of the c language :)
Bad and dangerous code can be written in any language. Don't blame
the tools for the incompetence of the workman.

bill
Arne Vajhøj
2017-06-27 01:33:20 UTC
Reply
Permalink
Raw Message
Post by Bill Gunshannon
Post by u***@gmail.com
Post by Scott Dorsey
Post by Arne Vajhøj
It proves that malware can work on VMS.
This particular vulnerability is of course fixed decades ago.
But has any changes been made to VMS since then that should
prevent all malware from running on VMS?
If anything, changes have been made to VMS since then which likely makes
vulnerabilities that can be exploited by new malware more frequent.
I claim that the number one cause of clear software vulnerabilities today is
the use of null-terminated strings, and until we get rid of the use of
C strings completely we will be having to worry about buffer overrun issues.
I would take that one step farther and get rid of the c language :)
Bad and dangerous code can be written in any language. Don't blame
the tools for the incompetence of the workman.
Bad and dangerous code can be written in any language.

But that does not mean that all languages are equal in
this regard.

Languages are being designed for different purposes.

Some languages has been designed for providing the
developer full access to everything.

Some languages has been designed to make it difficult
for the developer to make that type of mistakes.

Arne
Bill Gunshannon
2017-06-27 02:13:29 UTC
Reply
Permalink
Raw Message
Post by Bill Gunshannon
Post by Bill Gunshannon
Post by u***@gmail.com
Post by Scott Dorsey
Post by Arne Vajhøj
It proves that malware can work on VMS.
This particular vulnerability is of course fixed decades ago.
But has any changes been made to VMS since then that should
prevent all malware from running on VMS?
If anything, changes have been made to VMS since then which likely makes
vulnerabilities that can be exploited by new malware more frequent.
I claim that the number one cause of clear software vulnerabilities today is
the use of null-terminated strings, and until we get rid of the use of
C strings completely we will be having to worry about buffer overrun issues.
I would take that one step farther and get rid of the c language :)
Bad and dangerous code can be written in any language. Don't blame
the tools for the incompetence of the workman.
Bad and dangerous code can be written in any language.
But that does not mean that all languages are equal in
this regard.
Languages are being designed for different purposes.
Some languages has been designed for providing the
developer full access to everything.
Some languages has been designed to make it difficult
for the developer to make that type of mistakes.
Every language I know of (like Ada and Pascal) have extensions
to let the programmer get around those protections because they
also prevent the programmer from doing things that turn out to
be necessary in the real world.

bill
Arne Vajhøj
2017-06-27 02:34:45 UTC
Reply
Permalink
Raw Message
Post by Bill Gunshannon
Post by Bill Gunshannon
Post by Bill Gunshannon
Post by u***@gmail.com
I would take that one step farther and get rid of the c language :)
Bad and dangerous code can be written in any language. Don't blame
the tools for the incompetence of the workman.
Bad and dangerous code can be written in any language.
But that does not mean that all languages are equal in
this regard.
Languages are being designed for different purposes.
Some languages has been designed for providing the
developer full access to everything.
Some languages has been designed to make it difficult
for the developer to make that type of mistakes.
Every language I know of (like Ada and Pascal) have extensions
to let the programmer get around those protections because they
also prevent the programmer from doing things that turn out to
be necessary in the real world.
Disabling out of bounds checks is not necessary in all
real world applications.

Most likely only in very few of them.

I am not that experienced with Ada.

But I have done quite a bit of VMS Pascal (late 80's - mid 90's). And
I have never used /CHECK=NOBOUNDS.

And there are lots of languages where you can not disable
that check. Example Java.

And there are also languages where you don't disable
generally but just for a specific block, which
allows to disable only there when it is needed.
Example C# and unsafe blocks.

Arne
Bill Gunshannon
2017-06-27 12:40:32 UTC
Reply
Permalink
Raw Message
Post by Arne Vajhøj
Post by Bill Gunshannon
Post by Bill Gunshannon
Post by Bill Gunshannon
Post by u***@gmail.com
I would take that one step farther and get rid of the c language :)
Bad and dangerous code can be written in any language. Don't blame
the tools for the incompetence of the workman.
Bad and dangerous code can be written in any language.
But that does not mean that all languages are equal in
this regard.
Languages are being designed for different purposes.
Some languages has been designed for providing the
developer full access to everything.
Some languages has been designed to make it difficult
for the developer to make that type of mistakes.
Every language I know of (like Ada and Pascal) have extensions
to let the programmer get around those protections because they
also prevent the programmer from doing things that turn out to
be necessary in the real world.
Disabling out of bounds checks is not necessary in all
real world applications.
Most likely only in very few of them.
I am not that experienced with Ada.
But I have done quite a bit of VMS Pascal (late 80's - mid 90's). And
I have never used /CHECK=NOBOUNDS.
I didn't say it had to be done all the time. I said the
creators of the compilers recognized a need to do this when
they created the compiler regardless of what the original
language gurus thought.
Post by Arne Vajhøj
And there are lots of languages where you can not disable
that check. Example Java.
And it has very limited use. There are a lot of architectures that
it won't run on at all. It certainly couldn't be used to write an
OS designed to run on bare metal.
Post by Arne Vajhøj
And there are also languages where you don't disable
generally but just for a specific block, which
allows to disable only there when it is needed.
Example C# and unsafe blocks.
And some Pascals and I am sure others. But the point is, you
can disable them. And this was included specifically because
some times you have to. C just decided to keep the overhead
down by making it the default. Of course, the people designing
the language probably assumed it would be competent professionals
actually using it. Apparently a bad assumption on their part.

bill
Camiel Vanderhoeven
2017-06-27 12:59:44 UTC
Reply
Permalink
Raw Message
Post by Bill Gunshannon
Post by Arne Vajhøj
And there are lots of languages where you can not disable
that check. Example Java.
And it has very limited use. There are a lot of architectures that
it won't run on at all. It certainly couldn't be used to write an
OS designed to run on bare metal.
Don't forget about JavaOS on the picoJava processor.
Jan-Erik Soderholm
2017-06-27 13:25:23 UTC
Reply
Permalink
Raw Message
Post by Camiel Vanderhoeven
Post by Bill Gunshannon
Post by Arne Vajhøj
And there are lots of languages where you can not disable
that check. Example Java.
And it has very limited use. There are a lot of architectures that
it won't run on at all. It certainly couldn't be used to write an
OS designed to run on bare metal.
Don't forget about JavaOS on the picoJava processor.
Why not? Everyone else seems to have forgotten it.
Simon Clubley
2017-06-27 21:22:18 UTC
Reply
Permalink
Raw Message
Post by Bill Gunshannon
I didn't say it had to be done all the time. I said the
creators of the compilers recognized a need to do this when
they created the compiler regardless of what the original
language gurus thought.
And in the case of Ada, the "language gurus" were the ones who added
it to the language itself and they did it in such a way that it stood
out clearly at code review time.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Arne Vajhøj
2017-06-28 00:01:39 UTC
Reply
Permalink
Raw Message
Post by Bill Gunshannon
Post by Arne Vajhøj
Post by Bill Gunshannon
Post by Bill Gunshannon
Post by Bill Gunshannon
Post by u***@gmail.com
I would take that one step farther and get rid of the c language :)
Bad and dangerous code can be written in any language. Don't blame
the tools for the incompetence of the workman.
Bad and dangerous code can be written in any language.
But that does not mean that all languages are equal in
this regard.
Languages are being designed for different purposes.
Some languages has been designed for providing the
developer full access to everything.
Some languages has been designed to make it difficult
for the developer to make that type of mistakes.
Every language I know of (like Ada and Pascal) have extensions
to let the programmer get around those protections because they
also prevent the programmer from doing things that turn out to
be necessary in the real world.
Disabling out of bounds checks is not necessary in all
real world applications.
Most likely only in very few of them.
I am not that experienced with Ada.
But I have done quite a bit of VMS Pascal (late 80's - mid 90's). And
I have never used /CHECK=NOBOUNDS.
I didn't say it had to be done all the time. I said the
creators of the compilers recognized a need to do this when
they created the compiler regardless of what the original
language gurus thought.
True. It happens frequently that languages evolve.
Post by Bill Gunshannon
Post by Arne Vajhøj
And there are lots of languages where you can not disable
that check. Example Java.
And it has very limited use.
????

That is like saying motor vehicles with 4 wheels has limited
use.
Post by Bill Gunshannon
There are a lot of architectures that
it won't run on at all. It certainly couldn't be used to write an
OS designed to run on bare metal.
OS kernels is one of the areas that Java is not suited for.

But that is a very small niche.
Post by Bill Gunshannon
Post by Arne Vajhøj
And there are also languages where you don't disable
generally but just for a specific block, which
allows to disable only there when it is needed.
Example C# and unsafe blocks.
And some Pascals and I am sure others. But the point is, you
can disable them. And this was included specifically because
some times you have to. C just decided to keep the overhead
down by making it the default.
First this is not correct. It is not the default option
in C - it is the only option.

And even if there had been options then the default would
have been wrong.

We are comparing two types of languages:
A) languages that can not check array bounds
B) languages that by default and in 99.999% of actual code
does check array bounds

Question: in what language will most buffer overflows
happen.
Post by Bill Gunshannon
Of course, the people designing
the language probably assumed it would be competent professionals
actually using it. Apparently a bad assumption on their part.
It is a key concept to understand when discussing security that
people make mistakes.

You can hire the best 100 developers in the world, but if you
let them write enough lines of codes, then they will create
some bugs.

Good developers make fewer errors than bad developers, but they
still make errors.

The idea that you can hire sufficient good people and avoid bugs
is a total non-starter.

Arne
Bill Gunshannon
2017-06-28 00:43:46 UTC
Reply
Permalink
Raw Message
Post by Arne Vajhøj
Post by Bill Gunshannon
Post by Arne Vajhøj
Post by Bill Gunshannon
Post by Bill Gunshannon
Post by Bill Gunshannon
Post by u***@gmail.com
I would take that one step farther and get rid of the c language :)
Bad and dangerous code can be written in any language. Don't blame
the tools for the incompetence of the workman.
Bad and dangerous code can be written in any language.
But that does not mean that all languages are equal in
this regard.
Languages are being designed for different purposes.
Some languages has been designed for providing the
developer full access to everything.
Some languages has been designed to make it difficult
for the developer to make that type of mistakes.
Every language I know of (like Ada and Pascal) have extensions
to let the programmer get around those protections because they
also prevent the programmer from doing things that turn out to
be necessary in the real world.
Disabling out of bounds checks is not necessary in all
real world applications.
Most likely only in very few of them.
I am not that experienced with Ada.
But I have done quite a bit of VMS Pascal (late 80's - mid 90's). And
I have never used /CHECK=NOBOUNDS.
I didn't say it had to be done all the time. I said the
creators of the compilers recognized a need to do this when
they created the compiler regardless of what the original
language gurus thought.
True. It happens frequently that languages evolve.
Post by Bill Gunshannon
Post by Arne Vajhøj
And there are lots of languages where you can not disable
that check. Example Java.
And it has very limited use.
????
That is like saying motor vehicles with 4 wheels has limited
use.
Post by Bill Gunshannon
There are a lot of architectures that
it won't run on at all. It certainly couldn't be used to write an
OS designed to run on bare metal.
OS kernels is one of the areas that Java is not suited for.
But that is a very small niche.
Post by Bill Gunshannon
Post by Arne Vajhøj
And there are also languages where you don't disable
generally but just for a specific block, which
allows to disable only there when it is needed.
Example C# and unsafe blocks.
And some Pascals and I am sure others. But the point is, you
can disable them. And this was included specifically because
some times you have to. C just decided to keep the overhead
down by making it the default.
First this is not correct. It is not the default option
in C - it is the only option.
And even if there had been options then the default would
have been wrong.
A) languages that can not check array bounds
B) languages that by default and in 99.999% of actual code
does check array bounds
Question: in what language will most buffer overflows
happen.
COBOL. :-)
Post by Arne Vajhøj
Post by Bill Gunshannon
Of course, the people designing
the language probably assumed it would be competent professionals
actually using it. Apparently a bad assumption on their part.
It is a key concept to understand when discussing security that
people make mistakes.
You can hire the best 100 developers in the world, but if you
let them write enough lines of codes, then they will create
some bugs.
Good developers make fewer errors than bad developers, but they
still make errors.
The idea that you can hire sufficient good people and avoid bugs
is a total non-starter.
I have been writing C code for over 30 years. No code of mine has ever
had a buffer overflow.

bill
Paul Sture
2017-06-27 18:43:16 UTC
Reply
Permalink
Raw Message
<snip>
Post by Bill Gunshannon
Post by Bill Gunshannon
Bad and dangerous code can be written in any language.
But that does not mean that all languages are equal in
this regard.
Languages are being designed for different purposes.
Some languages has been designed for providing the
developer full access to everything.
Some languages has been designed to make it difficult
for the developer to make that type of mistakes.
Every language I know of (like Ada and Pascal) have extensions
to let the programmer get around those protections because they
also prevent the programmer from doing things that turn out to
be necessary in the real world.
But the programmer has to go out of their way to use those
extensions.

But that becomes a real problem when such code gets pasted into a reply
on the likes of Stack Overflow and used by those who don't understand it.
See Cargo Cult Programming.
--
Everybody has a testing environment. Some people are lucky enough to
have a totally separate environment to run production in.
Bill Gunshannon
2017-06-27 20:28:37 UTC
Reply
Permalink
Raw Message
Post by Elliott Roper
<snip>
Post by Bill Gunshannon
Post by Bill Gunshannon
Bad and dangerous code can be written in any language.
But that does not mean that all languages are equal in
this regard.
Languages are being designed for different purposes.
Some languages has been designed for providing the
developer full access to everything.
Some languages has been designed to make it difficult
for the developer to make that type of mistakes.
Every language I know of (like Ada and Pascal) have extensions
to let the programmer get around those protections because they
also prevent the programmer from doing things that turn out to
be necessary in the real world.
But the programmer has to go out of their way to use those
extensions.
But that becomes a real problem when such code gets pasted into a reply
on the likes of Stack Overflow and used by those who don't understand it.
See Cargo Cult Programming.
As I said in my next message:
"Of course, the people designing the language probably assumed
it would be competent professionals actually using it. Apparently
a bad assumption on their part. "

But, my previous comment still applies. Don't blame the tool for the
shortcomings of the workman.

bill
Arne Vajhøj
2017-06-28 00:06:49 UTC
Reply
Permalink
Raw Message
Post by Bill Gunshannon
Post by Paul Sture
Post by Bill Gunshannon
Post by Bill Gunshannon
Bad and dangerous code can be written in any language.
But that does not mean that all languages are equal in
this regard.
Languages are being designed for different purposes.
Some languages has been designed for providing the
developer full access to everything.
Some languages has been designed to make it difficult
for the developer to make that type of mistakes.
Every language I know of (like Ada and Pascal) have extensions
to let the programmer get around those protections because they
also prevent the programmer from doing things that turn out to
be necessary in the real world.
But the programmer has to go out of their way to use those
extensions.
But that becomes a real problem when such code gets pasted into a reply
on the likes of Stack Overflow and used by those who don't understand it.
See Cargo Cult Programming.
"Of course, the people designing the language probably assumed
it would be competent professionals actually using it. Apparently
a bad assumption on their part. "
But, my previous comment still applies. Don't blame the tool for the
shortcomings of the workman.
But we should blame the tool if its philosophy is based
on an assumption that is known to be untrue - that you can
get workmen that do not make mistakes.

Arne
Stephen Hoffman
2017-06-28 00:44:22 UTC
Reply
Permalink
Raw Message
But we should blame the tool if its philosophy is based on an
assumption that is known to be untrue - that you can get workmen that
do not make mistakes.
Ayup...

I've always wondered about the transition between the "blame the user"
response and the "hey, maybe this approach really has some problems"
response in these cases.

Empathy can certainly apply to various of these cases. Sometimes
folks screw up. Too many screw-ups though, and maybe some technical
changes are in order.

Then there are the discussions of how much collateral damage is
necessary before changes are considered and propagated?

Switching from C or C++ to some other appropriate choice is not cheap,
and won't reasonably happen in our respective lifetimes. Too much
installed code. New work and substantial updates, though; that can
happen. As can better C and C++ compilers and language updates that
reduce or eliminate specific triggers, identify undefined behavior, and
flag sketchy syntax. The move from VAX C to DEC C identified large
numbers of these cases, too; there's precedent even within OpenVMS.

Cases where users do get excessively blamed might well be product or
business or competitive opportunities, too.
--
Pure Personal Opinion | HoffmanLabs LLC
Arne Vajhøj
2017-06-28 00:47:32 UTC
Reply
Permalink
Raw Message
Post by Stephen Hoffman
Switching from C or C++ to some other appropriate choice is not cheap,
and won't reasonably happen in our respective lifetimes. Too much
installed code. New work and substantial updates, though; that can
happen. As can better C and C++ compilers and language updates that
reduce or eliminate specific triggers, identify undefined behavior, and
flag sketchy syntax. The move from VAX C to DEC C identified large
numbers of these cases, too; there's precedent even within OpenVMS.
Static code analysis tools has also become quite good today.

Arne
Stephen Hoffman
2017-06-28 01:52:19 UTC
Reply
Permalink
Raw Message
Post by Arne Vajhøj
Post by Stephen Hoffman
Switching from C or C++ to some other appropriate choice is not cheap,
and won't reasonably happen in our respective lifetimes. Too much
installed code. New work and substantial updates, though; that can
happen. As can better C and C++ compilers and language updates that
reduce or eliminate specific triggers, identify undefined behavior, and
flag sketchy syntax. The move from VAX C to DEC C identified large
numbers of these cases, too; there's precedent even within OpenVMS.
Static code analysis tools has also become quite good today.
Ayup. I use those, and they and good dynamic analysis tools are
integrated into the IDE and the environment on one of the platforms I
work with. Downside: not OpenVMS.
--
Pure Personal Opinion | HoffmanLabs LLC
Bob Koehler
2017-06-28 15:53:54 UTC
Reply
Permalink
Raw Message
Post by Bill Gunshannon
Bad and dangerous code can be written in any language. Don't blame
the tools for the incompetence of the workman.
True, but in sopme languages is trivial to get it wrong,
and in others it's trvial to get it right.

And that IS the fault of the tool.
Bill Gunshannon
2017-06-28 17:39:29 UTC
Reply
Permalink
Raw Message
Post by Bob Koehler
Post by Bill Gunshannon
Bad and dangerous code can be written in any language. Don't blame
the tools for the incompetence of the workman.
True, but in sopme languages is trivial to get it wrong,
and in others it's trvial to get it right.
And that IS the fault of the tool.
In no language is it trivial to get it right. It may be hard to
write dangerous code, but that is not all there is to getting it
right. Think "League of Their Own": "If it was easy, everybody
would do it."

bill
Arne Vajhøj
2017-06-30 00:07:09 UTC
Reply
Permalink
Raw Message
Post by Bill Gunshannon
Post by Bob Koehler
Post by Bill Gunshannon
Bad and dangerous code can be written in any language. Don't blame
the tools for the incompetence of the workman.
True, but in sopme languages is trivial to get it wrong,
and in others it's trvial to get it right.
And that IS the fault of the tool.
In no language is it trivial to get it right. It may be hard to
write dangerous code, but that is not all there is to getting it
right. Think "League of Their Own": "If it was easy, everybody
would do it."
Sure.

But it can help to pick a language that makes it hard to write
dangerous code (assuming that the task does not require dangerous
code).

Arne

Peter 'EPLAN' LANGSTOeGER
2017-06-29 07:59:19 UTC
Reply
Permalink
Raw Message
Post by Bob Koehler
Post by Bill Gunshannon
Bad and dangerous code can be written in any language. Don't blame
the tools for the incompetence of the workman.
True, but in sopme languages is trivial to get it wrong,
and in others it's trvial to get it right.
And that IS the fault of the tool.
I second that. In fact, I'm a C hater *because of this* and stopped doing
development at the time of K&R C (though ANSI C reduced my anger a little bit)
and I blame mainly C for the lack of security in U**X/Linux/Android/iOS
(and mainly Bill Gates personally for the lack of security in Windows)

just my 0.02
--
Peter "EPLAN" LANGSTÖGER
Network and OpenVMS system specialist
E-mail ***@LANGSTOeGER.at
A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist
Henry Crun
2017-06-26 16:34:42 UTC
Reply
Permalink
Raw Message
Post by u***@gmail.com
Post by Scott Dorsey
Post by Arne Vajhøj
It proves that malware can work on VMS.
This particular vulnerability is of course fixed decades ago.
But has any changes been made to VMS since then that should
prevent all malware from running on VMS?
If anything, changes have been made to VMS since then which likely makes
vulnerabilities that can be exploited by new malware more frequent.
I claim that the number one cause of clear software vulnerabilities today is
the use of null-terminated strings, and until we get rid of the use of
C strings completely we will be having to worry about buffer overrun issues.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
I would take that one step farther and get rid of the c language :)
The last good thing written in C was Franz Schubert's Symphony No. 9.
--
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
Paul Sture
2017-06-26 17:34:48 UTC
Reply
Permalink
Raw Message
Post by Henry Crun
Post by u***@gmail.com
Post by Scott Dorsey
Post by Arne Vajhøj
It proves that malware can work on VMS.
This particular vulnerability is of course fixed decades ago.
But has any changes been made to VMS since then that should
prevent all malware from running on VMS?
If anything, changes have been made to VMS since then which likely makes
vulnerabilities that can be exploited by new malware more frequent.
I claim that the number one cause of clear software vulnerabilities today is
the use of null-terminated strings, and until we get rid of the use of
C strings completely we will be having to worry about buffer overrun issues.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
I would take that one step farther and get rid of the c language :)
The last good thing written in C was Franz Schubert's Symphony No. 9.
Very subjective. I'd go for Terry Riley's "In C", myself:

<https://en.wikipedia.org/wiki/In_C>

"The piece begins on a C major chord (patterns one through seven) with a
strong emphasis on the mediant E and the entrance of the note F which
begins a series of slow progressions to other chords suggesting a few
subtle and ambiguous changes of key, the last pattern being an
alteration between B♭ and G. Though the polyphonic interplay of the
various patterns against each other and themselves at different rhythmic
displacements is of primary interest, the piece may be considered
heterophonic."

:-)
--
Everybody has a testing environment. Some people are lucky enough to
have a totally separate environment to run production in.
Elliott Roper
2017-06-26 20:11:34 UTC
Reply
Permalink
Raw Message
On 26 Jun 2017, Paul Sture wrote
(in article <o6t72e-***@news2.chingola.ch>):
<snip>
Post by Paul Sture
<https://en.wikipedia.org/wiki/In_C>
"The piece begins on a C major chord (patterns one through seven) with a
strong emphasis on the mediant E and the entrance of the note F which
begins a series of slow progressions to other chords suggesting a few
subtle and ambiguous changes of key, the last pattern being an
alteration between B♭ and G. Though the polyphonic interplay of the
various patterns against each other and themselves at different rhythmic
displacements is of primary interest, the piece may be considered
heterophonic."
-)
My only copy is performed by "european music project" and "zignori++"
I think there are musicians out there with coding ability and a dark sense of
humour.

"Standard Terry Library" ?
--
To de-mung my e-mail address:- fsnospam$elliott$$ PGP Fingerprint: 1A96 3CF7
637F 896B C810 E199 7E5C A9E4 8E59 E248
Hans Vlems
2017-06-26 17:36:03 UTC
Reply
Permalink
Raw Message
That is a very good joke :-)
Neil Rieck
2017-06-26 20:31:49 UTC
Reply
Permalink
Raw Message
Post by u***@gmail.com
Post by Scott Dorsey
Post by Arne Vajhøj
It proves that malware can work on VMS.
This particular vulnerability is of course fixed decades ago.
But has any changes been made to VMS since then that should
prevent all malware from running on VMS?
If anything, changes have been made to VMS since then which likely makes
vulnerabilities that can be exploited by new malware more frequent.
I claim that the number one cause of clear software vulnerabilities today is
the use of null-terminated strings, and until we get rid of the use of
C strings completely we will be having to worry about buffer overrun issues.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
I would take that one step farther and get rid of the c language :)
That will never happen.

Like it or not, C and C++ are the languages that built UNIX which enabled the internet which enabled Linux which now runs 50% of all the stuff on the planet. On top of that, almost all language compilers today are written in C/C++

http://www3.sympatico.ca/n.rieck/docs/technological_change.html#epiphany2

But to answer a previous post, zero length strings are not the problem; it is how they are used (static vs dynamic via malloc). We do a lot of stuff in this shop with DEC-BASIC talking to DEC-C and it is really easy to convert to-from "VMS style" strings when they are required.

Neil Rieck
Waterloo, Ontario, Canada.
Stephen Hoffman
2017-06-26 21:49:38 UTC
Reply
Permalink
Raw Message
Post by Neil Rieck
But to answer a previous post, zero length strings are not the problem;
it is how they are used (static vs dynamic via malloc).
I'm not sure I follow. (I've corrupted the stack and the heap with
BASIC code, too. It's somewhat harder than hosing the stack or the
heap with C, Macro32 or Bliss, but it's certainly feasible.) Placing
string metadata where it easily gets stomped on or truncated was a
problematic choice for C, and which is why some C string-handling calls
are better than others, and why compile-time flagging some of the more
problematic calls can be beneficial to developers.

Since you have some experience in another area, the null in a C string
has some similarities to the use of in-band signaling found in older
telephone systems. The results of that mixing of user data and
metadata together and in-band were... problematic. But I digress.
Post by Neil Rieck
We do a lot of stuff in this shop with DEC-BASIC talking to DEC-C and
it is really easy to convert to-from "VMS style" strings when they are
required.
I'd prefer a more standard way to call into C code from OpenVMS code
that expects descriptors, but most of us are using jackets for that.
Sometimes we end up with more jackets than we want, as has been
happening in cases where the OpenVMS C library diverges from C on other
platforms, too. We've been wrestling with these issues for more many
years, unfortunately.

All of this stuff also ties right back to those "OpenVMS is secure!"
threads, too. It's not just the platform itself — Linux, Unix, macOS,
OpenVMS, whatever – that gets into trouble with buffer overflows or
other vulnerabilities, it's also the apps. Making those apps easier to
write and to test (newer compiler standards, languages, frameworks),
more reliable against common coding mistakes (flagging any use of
strlen during a C compilation, for instance), more secure against
network shenanigans (easier frameworks combining networking, DNS,
encryption, authentication, certificate verification), and better
isolated in the event of a breach (BSD-style pledge, jails, app and
system address space randomization and no-execute, etc), is (would be)
a benefit to folks developing for and using OpenVMS servers. VSI is
working on pieces and parts here, too.
--
Pure Personal Opinion | HoffmanLabs LLC
Arne Vajhøj
2017-06-27 01:39:17 UTC
Reply
Permalink
Raw Message
Post by Neil Rieck
Post by u***@gmail.com
Post by Scott Dorsey
Post by Arne Vajhøj
It proves that malware can work on VMS.
This particular vulnerability is of course fixed decades ago.
But has any changes been made to VMS since then that should
prevent all malware from running on VMS?
If anything, changes have been made to VMS since then which likely makes
vulnerabilities that can be exploited by new malware more frequent.
I claim that the number one cause of clear software vulnerabilities today is
the use of null-terminated strings, and until we get rid of the use of
C strings completely we will be having to worry about buffer overrun issues.
I would take that one step farther and get rid of the c language :)
That will never happen.
Like it or not, C and C++ are the languages that built UNIX which
enabled the internet which enabled Linux which now runs 50% of all the
stuff on the planet.
It seems very likely that OS's will continue to be written in C/C++ for
many many decades to come.
Post by Neil Rieck
On top of that, almost all language compilers today
are written in C/C++
That is not required.

And I don't think it is even the case.

Java and .NET languages are certainly being used for compilers today.
Post by Neil Rieck
But to answer a previous post, zero length strings are not the
problem; it is how they are used (static vs dynamic via malloc).
I don't think static vs dynamic really matters much.

Static can be unsafe and dynamic can be unsafe.

What matters is whether out of bounds is being checked.

Zero terminated string usually means that the language/RTL does not
have a length to check for out of bounds.

Arne
Arne Vajhøj
2017-06-27 01:25:50 UTC
Reply
Permalink
Raw Message
Post by Scott Dorsey
Post by Arne Vajhøj
It proves that malware can work on VMS.
This particular vulnerability is of course fixed decades ago.
But has any changes been made to VMS since then that should
prevent all malware from running on VMS?
If anything, changes have been made to VMS since then which likely makes
vulnerabilities that can be exploited by new malware more frequent.
The code base has certainly increased and some of the "imported" code
may be not have been good quality (and VMS in some cases never got the
newer and better versions).
Post by Scott Dorsey
I claim that the number one cause of clear software vulnerabilities today is
the use of null-terminated strings, and until we get rid of the use of
C strings completely we will be having to worry about buffer overrun issues.
It is certainly a well known problem.

But I don't think it is #1.

Most top vulnerabilities today are web based.

Buffer overflow was #5 on OWASP top 10 in 2004
and did not make the list in 2007, 2010 or 2013.

Arne
MG
2017-06-23 09:36:38 UTC
Reply
Permalink
Raw Message
It's amusing to see people use terms like "nation-state", for
whatever reason(s), perhaps thinking it sounds more dignified,
spectacular or interesting, somehow.


« na-tion-state
[ney-shuh n-steyt]

noun
1. a sovereign state inhabited by a relatively
homogeneous group of people who share a feeling
of common nationality. »
[Dictionary.com:
<http://www.dictionary.com/browse/nation-state>]


« na·tion-state
(nā′shən-stāt′)
n.
A political unit consisting of an autonomous state
inhabited predominantly by a people sharing a common
culture, history, and language.

nation-state
n
(Government, Politics & Diplomacy) an independent
state inhabited by all the people of one nation and
one nation only »
[FreeDictionary.com:
<http://www.thefreedictionary.com/nation-state>]


« nation–state
na·tion–state \ˈnā-shən-ˈstāt, -ˌstāt\
noun

Definition
:
a form of political organization under which a
relatively homogeneous people inhabits a sovereign
state; especially
:
a state containing one as opposed to several
nationalities »
[Merriam-Webster:
<https://www.merriam-webster.com/dictionary/nation-state>]


In other words, the very last thing and arguably the complete
antithesis of what people generally think of when referring to
the US government.

- MG
Jan-Erik Soderholm
2017-06-23 09:45:46 UTC
Reply
Permalink
Raw Message
Post by MG
It's amusing to see people use terms like "nation-state", for
whatever reason(s), perhaps thinking it sounds more dignified,
spectacular or interesting, somehow.
« na-tion-state
[ney-shuh n-steyt]
noun
1. a sovereign state inhabited by a relatively
homogeneous group of people who share a feeling
of common nationality. »
<http://www.dictionary.com/browse/nation-state>]
« na·tion-state
(nā′shən-stāt′)
n.
A political unit consisting of an autonomous state
inhabited predominantly by a people sharing a common
culture, history, and language.
nation-state
n
(Government, Politics & Diplomacy) an independent
state inhabited by all the people of one nation and
one nation only »
<http://www.thefreedictionary.com/nation-state>]
« nation–state
na·tion–state \ˈnā-shən-ˈstāt, -ˌstāt\
noun
Definition
a form of political organization under which a
relatively homogeneous people inhabits a sovereign
state; especially
a state containing one as opposed to several
nationalities »
<https://www.merriam-webster.com/dictionary/nation-state>]
In other words, the very last thing and arguably the complete
antithesis of what people generally think of when referring to
the US government.
- MG
A "state" is fairly easy to understand, it is a piece of land
that has boarders to other "states".

But "nation" is much more loose in definition. That is the reason for
many of the "instabilities" today. There are many "states" that has
been just made up with no thought about the underlaying "nations"
that has been devided in "unatural" ways. The Middle East is the
most obviouse example of that today.

There are some that thinks that the best would be to disolve all current
"states" and just have one global "world". I don't know...
MG
2017-06-23 10:17:39 UTC
Reply
Permalink
Raw Message
Post by Jan-Erik Soderholm
But "nation" is much more loose in definition.
No, not according to most dictionary definitions at least.

To also reiterate my point: The US is _not_ a "nation-state".
Post by Jan-Erik Soderholm
That is the reason for many of the "instabilities" today. There are
many "states" that has been just made up with no thought about the
underlaying "nations" that has been devided in "unatural" ways. The
Middle East is the most obviouse example of that today.
You seem to confuse nation with state.
Post by Jan-Erik Soderholm
There are some that thinks that the best would be to disolve all current
"states" and just have one global "world". I don't know...
Sweden in particular appears to be trying to accomplish this
within their own borders.

- MG
Jan-Erik Soderholm
2017-06-23 10:24:44 UTC
Reply
Permalink
Raw Message
Post by MG
Post by Jan-Erik Soderholm
But "nation" is much more loose in definition.
No, not according to most dictionary definitions at least.
I just used the definitions your quoted. About common
culture and so on.
Post by MG
To also reiterate my point: The US is _not_ a "nation-state".
Agree. Not many seems to understand that.
Post by MG
Post by Jan-Erik Soderholm
That is the reason for many of the "instabilities" today. There are many
"states" that has been just made up with no thought about the underlaying
"nations" that has been devided in "unatural" ways. The Middle East is
the most obviouse example of that today.
You seem to confuse nation with state.
If you say so.
Post by MG
Post by Jan-Erik Soderholm
There are some that thinks that the best would be to disolve all current
"states" and just have one global "world". I don't know...
Sweden in particular appears to be trying to accomplish this
within their own borders.
- MG
Yes, I didn't say that everyone thinks that is a good idea... :-)
"The jury is still out" in that case, I guess...
Neil Rieck
2017-06-25 13:14:15 UTC
Reply
Permalink
Raw Message
Post by u***@gmail.com
so not only does the cia control windows hacking, but linux also.
OpenVMS not included because malware doesn't work on it.
http://youtu.be/w1-nmA5My7U
I was foolish enough to watch the whole video and there was no mention of Windows o Linux. But approximately two thirds though the author (conspiracy theorist David Seaman starts banging on about PizzaGate and PedoGate.

But to reply to the original post here in COV, anyone who is familiar with the revelations surrounding "stuxnet" or "operation olympic games" will already know that anyone can (eventually) get into any system.

Neil Rieck
Waterloo, Ontario, Canada.
http://www3.sympatico.ca/n.rieck/OpenVMS-Programmers-Corner.html
Loading...