Discussion:
What to do with my VAX.....
Add Reply
Bill Gunshannon
2020-10-17 14:10:32 UTC
Reply
Permalink
....now that VMS is going to be come persona non grata.

It has been decades, but, I used to work with an OS written by
Tannenbaum called Amoeba. A couple of grad students did a thesis
project on it using Sparcstations and it was really impressive to
watch it run. I had forgotten that it also ran on the VAX. Might
be fun to put it on my stack of VAXStations and see what it might
do.

By the way, for those who think that VMS is the only real share
everything clustering system, Amoeba was really good about sharing.
Too bad, like so many academic endeavors, people got bored with it
and it withered on the vine. Like Plan9 and Inferno.

bill
seasoned_geek
2020-10-18 09:17:29 UTC
Reply
Permalink
Post by Bill Gunshannon
....now that VMS is going to be come persona non grata.
It has been decades, but, I used to work with an OS written by
Tannenbaum called Amoeba. A couple of grad students did a thesis
project on it using Sparcstations and it was really impressive to
watch it run. I had forgotten that it also ran on the VAX. Might
be fun to put it on my stack of VAXStations and see what it might
do.
By the way, for those who think that VMS is the only real share
everything clustering system, Amoeba was really good about sharing.
Too bad, like so many academic endeavors, people got bored with it
and it withered on the vine. Like Plan9 and Inferno.
bill
I would posit the theory that people didn't "get bored with it" per se. They simply found out they would have to finance their own vices of eating and living indoors. Nobody was paying them to work on/with Amoeba.

If you do get it running and happen to have full source, you should probably start an OpenSource project on sourceforge.

There is a growing need for an OS without any TCP/IP stack. *nix did it wrong. There is absolutely no way of securing any system using *nix based TCP/IP when it is connected to the Internet. Lots of places dusting off old proprietary protocols for internal networks, putting one or two sacrificial machines out on the Internet and only installing/allowing the proprietary protocol between them and the internal network.
Grant Taylor
2020-10-18 17:34:20 UTC
Reply
Permalink
Post by seasoned_geek
There is a growing need for an OS without any TCP/IP stack. *nix did
it wrong. There is absolutely no way of securing any system using
*nix based TCP/IP when it is connected to the Internet.
I can't agree with that.

Sure, putting a system on the Internet exposes it to more harm than
sitting in a room by itself with no external connectivity. But then
again, powering the system on exposes it to more harm than completely
disconnecting it from power.

Also, anything with a TCP/IP stack can potentially be attacked across
the Internet, not just *nix.
Post by seasoned_geek
Lots of places dusting off old proprietary protocols for internal
networks, putting one or two sacrificial machines out on the Internet
and only installing/allowing the proprietary protocol between them
and the internal network.
I don't agree that using a different protocol makes the systems
inherently more secure.

What using a different protocol does is make it inherently harder to
access the systems using said protocol. But if there is a single system
that is using both TCP/IP and the other protocol, then it's possible to
pass through that system to get to the other systems. Thereby doing a
protocol translation.

Judicious firewalling can offer the same level of protection for the
other systems without the complexity of the other protocol(s).

What the other protocols do offer is making the other systems
incompatible with the Internet, thus meaning that they can't
/accidentally/ or /inadvertently/ communicate with the Internet if
(when) the firewall becomes misconfigured. This is a belt and
suspenders redundant security configuration. /Combined/ they make a
stronger configuration. But, in my opinion, neither is stronger than
the other when use individually.

If anything, having additional protocols means additional lines of code
which is tantamount to additional attack surface.
--
Grant. . . .
unix || die
Arne Vajhøj
2020-10-18 18:21:05 UTC
Reply
Permalink
Post by Grant Taylor
Post by seasoned_geek
There is a growing need for an OS without any TCP/IP stack. *nix did
it wrong. There is absolutely no way of securing any system using *nix
based TCP/IP when it is connected to the Internet.
I can't agree with that.
Sure, putting a system on the Internet exposes it to more harm than
sitting in a room by itself with no external connectivity.  But then
again, powering the system on exposes it to more harm than completely
disconnecting it from power.
Also, anything with a TCP/IP stack can potentially be attacked across
the Internet, not just *nix.
Yep.

And in fact most servers on the internet are running *nix (assuming
Linux is included in "*nix").
Post by Grant Taylor
Post by seasoned_geek
Lots of places dusting off old proprietary protocols for internal
networks, putting one or two sacrificial machines out on the Internet
and only installing/allowing the proprietary protocol between them and
the internal network.
I don't agree that using a different protocol makes the systems
inherently more secure.
Yep.

The TCP/IP protocols are probably some of the more secure just
because they have been examined and tested in depth.
Post by Grant Taylor
Judicious firewalling can offer the same level of protection for the
other systems without the complexity of the other protocol(s).
What the other protocols do offer is making the other systems
incompatible with the Internet, thus meaning that they can't
/accidentally/ or /inadvertently/ communicate with the Internet if
(when) the firewall becomes misconfigured.  This is a belt and
suspenders redundant security configuration.
Such a misconfiguration is not likely to happen.

If the firewall does nothing then nothing will get through since the
internal IP addresses will not be accessible.

Rules get added to forward a specific port to a specific IP address
and port.

There should not be any way to add wildcard forwarding.

There can be benefits from:

--(protocol A)--intermediate box--(protocol B)--real box

since it is more difficult to exploit protocol problems to
hit the real box.
Post by Grant Taylor
If anything, having additional protocols means additional lines of code
which is tantamount to additional attack surface.
Non-TCP/IP is usually a total non-starter.

Today very few places run only their own stuff on top of the OS. They
use lots of third party software.

And that third party software typical expect TCP/IP today.

Arne
seasoned_geek
2020-10-18 23:33:28 UTC
Reply
Permalink
Post by Grant Taylor
Post by seasoned_geek
There is a growing need for an OS without any TCP/IP stack. *nix did
it wrong. There is absolutely no way of securing any system using
*nix based TCP/IP when it is connected to the Internet.
I can't agree with that.
Well you should because it is reality. Even TLS/SSL isn't secure despite the name.
Post by Grant Taylor
Post by seasoned_geek
Lots of places dusting off old proprietary protocols for internal
networks, putting one or two sacrificial machines out on the Internet
and only installing/allowing the proprietary protocol between them
and the internal network.
I don't agree that using a different protocol makes the systems
inherently more secure.
What using a different protocol does is make it inherently harder to
access the systems using said protocol.
You know, the fans of TCP/IP never cease to amaze me. They continually claim that making something more difficult to access doesn't make it more secure then they talk about the various forms of encryption used with TCP/IP as "secure" when they are not. All encryption is security via obscurity. You're just bragging about the size of the forest you are hiding the tree in, but you are still just hiding a tree in a forest. A hacker doesn't need to find every tree, just the one they are looking for.
Post by Grant Taylor
But if there is a single system
that is using both TCP/IP and the other protocol, then it's possible to
pass through that system to get to the other systems. Thereby doing a
protocol translation.
No, it's not. That's an x86 view of the world. That there must be this pool of services exposed to the network and said services must map to known TCP/IP services like telnet, ftp, etc.

The systems I'm seeing and which appear to be getting quite common are Hub & Spoke. Out here the end of the spoke is a sacrificial x86 computer with a wanna-be OS. It runs TCP/IP and is exposed to the Internet.

Inside of the company, the real computers run a different networking protocol. They have no traditional services. There is no "protocol translation" happening. On the sacrificial computer some set of icky nasty free format (i.e. XML, JSON, etc.) messages come in. Those messages are then converted into fixed field width fixed length proprietary internal messages and placed on the message queue for one of the real machines. The only connection to the outside world the real computers have is these message queues. The only connection to the outside world any device on the internal network has is via the message queues completely controlled by one of the real machines.

Companies have been doing this since the early days of MQ Series on OS/2 and they continue to do it with various Websphere type solutions. The sacrificial x86 box runs Websphere (or your favorite Internet capable message queuing product). There is a completely different NIC using a completely different set of wire running a completely different protocol messaging back to the real computers. Most of the Websphere shops I've encountered operate in this manner.

The only way to access one of the real computers is to have a computer physically on that network. Most operate that network like a dial-up VPN. When that network connection is in use, TCP/IP is physically disabled. You have no external Internet or other network access.
Post by Grant Taylor
Judicious firewalling can offer the same level of protection for the
other systems without the complexity of the other protocol(s).
Not even in a fantasy world can a firewall offer the above level of security and up-time. While I will admit that many smaller companies purchase Websphere without knowing how to properly architect systems around it, most of the big ones do know and IBM sells a lot of Websphere.
Post by Grant Taylor
What the other protocols do offer is making the other systems
incompatible with the Internet, thus meaning that they can't
/accidentally/ or /inadvertently/ communicate with the Internet if
(when) the firewall becomes misconfigured. This is a belt and
suspenders redundant security configuration. /Combined/ they make a
stronger configuration. But, in my opinion, neither is stronger than
the other when use individually.
If anything, having additional protocols means additional lines of code
which is tantamount to additional attack surface.
See above.
Arne Vajhøj
2020-11-04 02:24:12 UTC
Reply
Permalink
On Sunday, October 18, 2020 at 12:34:14 PM UTC-5, Grant Taylor
Post by Grant Taylor
Post by seasoned_geek
There is a growing need for an OS without any TCP/IP stack. *nix
did it wrong. There is absolutely no way of securing any system
using *nix based TCP/IP when it is connected to the Internet.
I can't agree with that.
Well you should because it is reality. Even TLS/SSL isn't secure despite the name.
Anyone breaking current TLS could become very rich.
Post by Grant Taylor
Post by seasoned_geek
Lots of places dusting off old proprietary protocols for
internal networks, putting one or two sacrificial machines out on
the Internet and only installing/allowing the proprietary
protocol between them and the internal network.
I don't agree that using a different protocol makes the systems
inherently more secure.
What using a different protocol does is make it inherently harder
to access the systems using said protocol.
You know, the fans of TCP/IP never cease to amaze me. They
continually claim that making something more difficult to access
doesn't make it more secure then they talk about the various forms
of encryption used with TCP/IP as "secure" when they are not. All
encryption is security via obscurity.
No.

Security by obscurity is when the security relies on the
algorithm being kept secret.

A public known algorithm with a key kept secret is not
security by obscurity.
You're just bragging about the size of the forest you are hiding the
tree in, but you are still just hiding a tree in a forest. A hacker
doesn't need to find every tree, just the one they are looking for.
IT security is a practical discipline.

If the expected/average time to brute force a key guess
is 10 billion years, then people are willing to accept
that there is a probability extremely small but still greater
than zero that the first key guess is the correct one.
Post by Grant Taylor
But if there is a single system that is using both TCP/IP and the
other protocol, then it's possible to pass through that system to
get to the other systems. Thereby doing a protocol translation.
No, it's not. That's an x86 view of the world. That there must be
this pool of services exposed to the network and said services must
map to known TCP/IP services like telnet, ftp, etc.> The systems I'm
seeing and which appear to be getting quite common are Hub & Spoke.
Out here the end of the spoke is a sacrificial x86 computer with a
wanna-be OS. It runs TCP/IP and is exposed to the Internet.
Almost all enterprise IT is TCP/IP today.

The OS comes with TCP/IP.

If the programming language has builtin support for network
then it is TCP/IP.

Web servers are by definition TCP/IP based.

App servers typical only support TCP/IP.

Most databases only support TCP/IP for remote access.

Most message queues only support TCP/IP for remote access.

Most network boxes only handle TCP/IP.

It is very difficult to avoid TCP/IP.
Inside of the company, the real computers run a different networking
protocol. They have no traditional services. There is no "protocol
translation" happening. On the sacrificial computer some set of icky
nasty free format (i.e. XML, JSON, etc.) messages come in. Those
messages are then converted into fixed field width fixed length
proprietary internal messages and placed on the message queue for
one of the real machines. The only connection to the outside world
the real computers have is these message queues. The only connection
to the outside world any device on the internal network has is via
the message queues completely controlled by one of the real
machines.
Most message queues will require TCP/IP.
Companies have been doing this since the early days of MQ Series on
OS/2 and they continue to do it with various Websphere type
solutions. The sacrificial x86 box runs Websphere (or your favorite
Internet capable message queuing product). There is a completely
different NIC using a completely different set of wire running a
completely different protocol messaging back to the real computers.
Most of the Websphere shops I've encountered operate in this manner.
IBM MQ does support LU6.2 as alternative to TCP/IP.

But don't hold you breath waiting for SNA to take over
modern networking.

:-)
Post by Grant Taylor
Judicious firewalling can offer the same level of protection for
the other systems without the complexity of the other protocol(s).
Not even in a fantasy world can a firewall offer the above level of
security and up-time.
What you described above is a firewall.

One NIC on the outside and one NIC on the inside and no way
to the inside systems except through the 2 NIC box - that is
what is called a firewall.

And since there is no access to the inside network,
then the security benefits of another protocol
on the inside network are not that big.

Arne
seasoned_geek
2020-11-11 16:52:56 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by seasoned_geek
Post by Grant Taylor
Judicious firewalling can offer the same level of protection for
the other systems without the complexity of the other protocol(s).
Not even in a fantasy world can a firewall offer the above level of
security and up-time.
What you described above is a firewall.
One NIC on the outside and one NIC on the inside and no way
to the inside systems except through the 2 NIC box - that is
what is called a firewall.
And since there is no access to the inside network,
then the security benefits of another protocol
on the inside network are not that big.
No Arne,
Like all too many things you feel compelled to comment on, this is something you know nothing about.

The vast majority of firewalls aren't hardware at all.

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/sec-using_firewalls
https://openport.net/centos-firewall/
https://www.ubuntu18.com/how-to-enable-ubuntu-firewall-in-ubuntu-20-04/

https://www.windowscentral.com/how-open-port-windows-firewall

Even when one has a firewall in a router, PASSTHROUGH PORTS ARE ENABLED for many things.

https://www.tomsguide.com/us/how-to-vpn-firewall,review-139.html

A firewall isn't even remotely close to what I described. Not even on an acid trip.

A firewall is not taking a free-form XML/whatever "open" Internet message and chopping it down into a fixed field length fixed record width message for a queue. This means the people stuffing a billing characters or some other nonsense into that free format message to trigger an overrun so they can perform an SQL injection or some other hack physically can't happen. When someone tries to move a billion characters into a COBOL PIC X(25) field, what happens? The first 25 characters make it and the rest land in the bit bucket.

You are completely incorrect about Security by Obscurity as well. ALL ENCRYPTION is security by obscurity. Period.

Security breaches happen a lot.
https://www.cshub.com/attacks/articles/top-5-cyber-security-breaches-of-2019-so-far

I haven't had time to get back to it given the pandemic, passing of my father and the new book, but it appears TLS currently has a TOD sensitivity. One that could be easily exploited with a bot-net of just a few thousand computers and a few WD Black hard drives to store the data. I wanted to dedicate a few machines to generating the database but haven't had time. What assists the exploit is knowing the vast majority of XML messages have the exact same Prolog.

<?xml version="1.0" encoding="UTF-8"?>
Alexander Schreiber
2020-11-11 23:56:18 UTC
Reply
Permalink
Post by seasoned_geek
You are completely incorrect about Security by Obscurity as well. ALL
ENCRYPTION is security by obscurity. Period.
Thus proving nicely that you know _absolutely_ nothing about encryption.
You imight want to read up on Kerckhoff's principle for starters.
Post by seasoned_geek
Security breaches happen a lot.
https://www.cshub.com/attacks/articles/top-5-cyber-security-breaches-of-2019-so-far
Lets see:
1. misconfigured web application firewall -> configuration error
2. credential stuffing -> application design error
3. more credential stuffing -> application design error
4. "cloud vulnerability" -> can be anything but most likely
boils down to "we have no idea what we're even doing"
5. spear phishing -> the classic combination of employees
making minor mistakes and a bad security setup that allows
those to blow up into a breach - there are well known ways
to avoid that (and no, firing employees for reading the
wrong email is not it)
6. Yahoo was phished ... somebody forgot about defense in depth
7. Health care industry ... notorious for amazing incompentence
about these newfangled computer thingies (especially on the
vendor side)

I'm not going through all of them, but credential stuffing and phishing is
a common theme. Both can be defended against by proper system design and
security in depth, including proper internal access controls (no, the
CEO does _not_ need full access to all production systems just because
he is the boss).

But nothing of the above is related to Unix per se - it's design errors,
system config errors, bad access controls ... or in short: incompetence.
And that is a lot more common, than one might think, sadly.

Kind regards,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
Dave Froble
2020-11-12 01:54:44 UTC
Reply
Permalink
Post by Alexander Schreiber
Post by seasoned_geek
ALL
ENCRYPTION is security by obscurity. Period.
Thus proving nicely that you know _absolutely_ nothing about encryption.
You imight want to read up on Kerckhoff's principle for starters.
Well, I wouldn't be so quick to dismiss that statement.

Isn't not knowing a solution a form of obscurity? Otherwise, if one
knows the key, then there is no security, right? So not knowing the key
is sort of "security by obscurity"?

There have been multiple instances in the past of codes being broken and
harmful affects because of that. The Japanese code in WWII?

What is a "secret key", other than "unknown data"? Can such a key be
guessed? Unlikely. But possible.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Bill Gunshannon
2020-11-12 02:12:16 UTC
Reply
Permalink
Post by Dave Froble
Post by Alexander Schreiber
Post by seasoned_geek
ALL
ENCRYPTION is security by obscurity. Period.
Thus proving nicely that you know _absolutely_ nothing about encryption.
You imight want to read up on Kerckhoff's principle for starters.
Well, I wouldn't be so quick to dismiss that statement.
Isn't not knowing a solution a form of obscurity?  Otherwise, if one
knows the key, then there is no security, right?  So not knowing the key
is sort of "security by obscurity"?
There have been multiple instances in the past of codes being broken and
harmful affects because of that.  The Japanese code in WWII?
What is a "secret key", other than "unknown data"?  Can such a key be
guessed?  Unlikely.  But possible.
Guess it depends on which part of ENCRYPTION you are talking about.
The entire algorithm for the Unix Password encryption is documented
and available for anyone who wants to read it. No obscurity involved
at all. Let me know when you figure out how to reverse the encryption
for any password. Brute force doesn't count.

bill
Dave Froble
2020-11-12 03:40:56 UTC
Reply
Permalink
Post by Bill Gunshannon
Post by Dave Froble
Post by Alexander Schreiber
Post by seasoned_geek
ALL
ENCRYPTION is security by obscurity. Period.
Thus proving nicely that you know _absolutely_ nothing about encryption.
You imight want to read up on Kerckhoff's principle for starters.
Well, I wouldn't be so quick to dismiss that statement.
Isn't not knowing a solution a form of obscurity? Otherwise, if one
knows the key, then there is no security, right? So not knowing the
key is sort of "security by obscurity"?
There have been multiple instances in the past of codes being broken
and harmful affects because of that. The Japanese code in WWII?
What is a "secret key", other than "unknown data"? Can such a key be
guessed? Unlikely. But possible.
Guess it depends on which part of ENCRYPTION you are talking about.
The entire algorithm for the Unix Password encryption is documented
and available for anyone who wants to read it. No obscurity involved
at all. Let me know when you figure out how to reverse the encryption
for any password. Brute force doesn't count.
bill
But, it would be possible, however very unlikely, to guess? Or is that
considered "brute force"?
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Arne Vajhøj
2020-11-12 03:50:12 UTC
Reply
Permalink
Post by Bill Gunshannon
Post by Dave Froble
Post by Alexander Schreiber
Post by seasoned_geek
ALL
ENCRYPTION is security by obscurity. Period.
Thus proving nicely that you know _absolutely_ nothing about encryption.
You imight want to read up on Kerckhoff's principle for starters.
Well, I wouldn't be so quick to dismiss that statement.
Isn't not knowing a solution a form of obscurity?  Otherwise, if one
knows the key, then there is no security, right?  So not knowing the
key is sort of "security by obscurity"?
There have been multiple instances in the past of codes being broken
and harmful affects because of that.  The Japanese code in WWII?
What is a "secret key", other than "unknown data"?  Can such a key be
guessed?  Unlikely.  But possible.
Guess it depends on which part of ENCRYPTION you are talking about.
The entire algorithm for the Unix Password encryption is documented
and available for anyone who wants to read it.  No obscurity involved
at all.  Let me know when you figure out how to reverse the encryption
for any password.  Brute force doesn't count.
But, it would be possible, however very unlikely, to guess?  Or is that
considered "brute force"?
AES 256 bit has 2 power 256 possible keys.

That means that at average one will need to try 2 power 255 keys
before finding the correct one.

But one could be lucky and find it at first guess. Probability is
1 out of 2 power 256 for that happening.

Such odds are considered acceptable.

Arne
Bill Gunshannon
2020-11-12 15:25:58 UTC
Reply
Permalink
Post by Bill Gunshannon
Post by Dave Froble
Post by Alexander Schreiber
Post by seasoned_geek
ALL
ENCRYPTION is security by obscurity. Period.
Thus proving nicely that you know _absolutely_ nothing about encryption.
You imight want to read up on Kerckhoff's principle for starters.
Well, I wouldn't be so quick to dismiss that statement.
Isn't not knowing a solution a form of obscurity?  Otherwise, if one
knows the key, then there is no security, right?  So not knowing the
key is sort of "security by obscurity"?
There have been multiple instances in the past of codes being broken
and harmful affects because of that.  The Japanese code in WWII?
What is a "secret key", other than "unknown data"?  Can such a key be
guessed?  Unlikely.  But possible.
Guess it depends on which part of ENCRYPTION you are talking about.
The entire algorithm for the Unix Password encryption is documented
and available for anyone who wants to read it.  No obscurity involved
at all.  Let me know when you figure out how to reverse the encryption
for any password.  Brute force doesn't count.
bill
But, it would be possible, however very unlikely, to guess?  Or is that
considered "brute force"?
More likely that would be considered HUMINT.

But if you are going to use that kind of an argument than it can be
equally applied to everything. VMS isn't secure because it is possible,
no matter how unlikely, that someone can breach it.

bill
Arne Vajhøj
2020-11-12 15:53:48 UTC
Reply
Permalink
Post by Bill Gunshannon
Post by Bill Gunshannon
Post by Dave Froble
Post by Alexander Schreiber
Post by seasoned_geek
ALL
ENCRYPTION is security by obscurity. Period.
Thus proving nicely that you know _absolutely_ nothing about encryption.
You imight want to read up on Kerckhoff's principle for starters.
Well, I wouldn't be so quick to dismiss that statement.
Isn't not knowing a solution a form of obscurity?  Otherwise, if one
knows the key, then there is no security, right?  So not knowing the
key is sort of "security by obscurity"?
There have been multiple instances in the past of codes being broken
and harmful affects because of that.  The Japanese code in WWII?
What is a "secret key", other than "unknown data"?  Can such a key be
guessed?  Unlikely.  But possible.
Guess it depends on which part of ENCRYPTION you are talking about.
The entire algorithm for the Unix Password encryption is documented
and available for anyone who wants to read it.  No obscurity involved
at all.  Let me know when you figure out how to reverse the encryption
for any password.  Brute force doesn't count.
But, it would be possible, however very unlikely, to guess?  Or is
that considered "brute force"?
More likely that would be considered HUMINT.
But if you are going to use that kind of an argument than it can be
equally applied to everything.  VMS isn't secure because it is possible,
no matter how unlikely, that someone can breach it.
If you go to the login prompt and enter SYSTEM for username and
some random password, then there is some probability (extremely small,
but greater than zero) that the first guess on password will work.

Arne
Dave Froble
2020-11-12 16:20:21 UTC
Reply
Permalink
Post by Bill Gunshannon
Post by Dave Froble
Post by Bill Gunshannon
Post by Dave Froble
Post by Alexander Schreiber
Post by seasoned_geek
ALL
ENCRYPTION is security by obscurity. Period.
Thus proving nicely that you know _absolutely_ nothing about encryption.
You imight want to read up on Kerckhoff's principle for starters.
Well, I wouldn't be so quick to dismiss that statement.
Isn't not knowing a solution a form of obscurity? Otherwise, if one
knows the key, then there is no security, right? So not knowing the
key is sort of "security by obscurity"?
There have been multiple instances in the past of codes being broken
and harmful affects because of that. The Japanese code in WWII?
What is a "secret key", other than "unknown data"? Can such a key be
guessed? Unlikely. But possible.
Guess it depends on which part of ENCRYPTION you are talking about.
The entire algorithm for the Unix Password encryption is documented
and available for anyone who wants to read it. No obscurity involved
at all. Let me know when you figure out how to reverse the encryption
for any password. Brute force doesn't count.
bill
But, it would be possible, however very unlikely, to guess? Or is
that considered "brute force"?
More likely that would be considered HUMINT.
But if you are going to use that kind of an argument than it can be
equally applied to everything. VMS isn't secure because it is possible,
no matter how unlikely, that someone can breach it.
bill
Bingo! We have a winner. Hand him a qupie doll.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
seasoned_geek
2020-11-20 14:50:43 UTC
Reply
Permalink
Post by Bill Gunshannon
Post by seasoned_geek
ALL
ENCRYPTION is security by obscurity. Period.
But, it would be possible, however very unlikely, to guess? Or is that
considered "brute force"?
More likely that would be considered HUMINT.
But if you are going to use that kind of an argument than it can be
equally applied to everything. VMS isn't secure because it is possible,
no matter how unlikely, that someone can breach it.
Correct. If it isn't air-gapped it isn't secure from the outside world. Inside world it cannot really be secured from. You can only buy time and hope someone notices what is going on.
seasoned_geek
2020-11-20 12:42:35 UTC
Reply
Permalink
Post by Bill Gunshannon
Guess it depends on which part of ENCRYPTION you are talking about.
The entire algorithm for the Unix Password encryption is documented
and available for anyone who wants to read it. No obscurity involved
at all. Let me know when you figure out how to reverse the encryption
for any password. Brute force doesn't count.
bill
But, it would be possible, however very unlikely, to guess? Or is that
considered "brute force"?
I prefer reading the yellow sticky stuck to the monitor. Then again, in today's world, you can just breach their Google/Microsoft drive and look for a file named "login-notes.txt" or "account-info.txt" where, by virtue of each and every place having different password rules, now end up keeping login information for all of their accounts.
Bob Eager
2020-11-12 12:59:54 UTC
Reply
Permalink
Post by Dave Froble
Post by Alexander Schreiber
Post by seasoned_geek
ALL ENCRYPTION is security by obscurity. Period.
Thus proving nicely that you know _absolutely_ nothing about
encryption.
You imight want to read up on Kerckhoff's principle for starters.
Well, I wouldn't be so quick to dismiss that statement.
Isn't not knowing a solution a form of obscurity?  Otherwise, if one
knows the key, then there is no security, right?  So not knowing the
key is sort of "security by obscurity"?
There have been multiple instances in the past of codes being broken
and harmful affects because of that.  The Japanese code in WWII?
What is a "secret key", other than "unknown data"?  Can such a key be
guessed?  Unlikely.  But possible.
Guess it depends on which part of ENCRYPTION you are talking about. The
entire algorithm for the Unix Password encryption is documented and
available for anyone who wants to read it. No obscurity involved at
all. Let me know when you figure out how to reverse the encryption for
any password. Brute force doesn't count.
Originally documented in Boris Hagelin's patent, in mechanical form.
--
My posts are my copyright and if @diy_forums or Home Owners' Hub
wish to copy them they can pay me £1 a message.
Use the BIG mirror service in the UK: http://www.mirrorservice.org
*lightning surge protection* - a w_tom conductor
Arne Vajhøj
2020-11-12 03:47:21 UTC
Reply
Permalink
Post by Dave Froble
Post by Alexander Schreiber
Post by seasoned_geek
ALL
ENCRYPTION is security by obscurity. Period.
Thus proving nicely that you know _absolutely_ nothing about encryption.
You imight want to read up on Kerckhoff's principle for starters.
Well, I wouldn't be so quick to dismiss that statement.
Isn't not knowing a solution a form of obscurity?  Otherwise, if one
knows the key, then there is no security, right?  So not knowing the key
is sort of "security by obscurity"?
There have been multiple instances in the past of codes being broken and
harmful affects because of that.  The Japanese code in WWII?
What is a "secret key", other than "unknown data"?  Can such a key be
guessed?  Unlikely.  But possible.
Security by obscurity has a very specific meaning.

It is when the security depends on the algorithm being kept secret.

This is generally considered bad.

And none of the standard algorithms today use it.

You can open any text book on encryption and see the algorithms
for AES, RSA etc. and they are still prohibitively difficult
to crack.

AES 256 bit has a 256 bit key. That is 2 power 256 possible keys.
That is a big number.

Arne
Dave Froble
2020-11-12 08:59:06 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by Dave Froble
Post by Alexander Schreiber
Post by seasoned_geek
ALL
ENCRYPTION is security by obscurity. Period.
Thus proving nicely that you know _absolutely_ nothing about encryption.
You imight want to read up on Kerckhoff's principle for starters.
Well, I wouldn't be so quick to dismiss that statement.
Isn't not knowing a solution a form of obscurity? Otherwise, if one
knows the key, then there is no security, right? So not knowing the
key is sort of "security by obscurity"?
There have been multiple instances in the past of codes being broken
and harmful affects because of that. The Japanese code in WWII?
What is a "secret key", other than "unknown data"? Can such a key be
guessed? Unlikely. But possible.
Security by obscurity has a very specific meaning.
That's kind of narrow thinking, isn't it?
Post by Arne Vajhøj
It is when the security depends on the algorithm being kept secret.
This is generally considered bad.
And none of the standard algorithms today use it.
You can open any text book on encryption and see the algorithms
for AES, RSA etc. and they are still prohibitively difficult
to crack.
AES 256 bit has a 256 bit key. That is 2 power 256 possible keys.
That is a big number.
I agree with all that, but, the statement seems to still apply, at least
to me. If one doesn't know how to access, then, it is obscure, or by
the statement, unknown, right?
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Jan-Erik Söderholm
2020-11-12 09:19:50 UTC
Reply
Permalink
Post by Dave Froble
Post by Arne Vajhøj
Post by Dave Froble
Post by Alexander Schreiber
Post by seasoned_geek
ALL
ENCRYPTION is security by obscurity. Period.
Thus proving nicely that you know _absolutely_ nothing about encryption.
You imight want to read up on Kerckhoff's principle for starters.
Well, I wouldn't be so quick to dismiss that statement.
Isn't not knowing a solution a form of obscurity?  Otherwise, if one
knows the key, then there is no security, right?  So not knowing the
key is sort of "security by obscurity"?
There have been multiple instances in the past of codes being broken
and harmful affects because of that.  The Japanese code in WWII?
What is a "secret key", other than "unknown data"?  Can such a key be
guessed?  Unlikely.  But possible.
Security by obscurity has a very specific meaning.
That's kind of narrow thinking, isn't it?
Post by Arne Vajhøj
It is when the security depends on the algorithm being kept secret.
This is generally considered bad.
And none of the standard algorithms today use it.
You can open any text book on encryption and see the algorithms
for AES, RSA etc. and they are still prohibitively difficult
to crack.
AES 256 bit has a 256 bit key. That is 2 power 256 possible keys.
That is a big number.
I agree with all that, but, the statement seems to still apply, at least to
me.  If one doesn't know how to access, then, it is obscure, or by the
statement, unknown, right?
That is only you (as usual).

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

"System security should not depend on the secrecy of the implementation
or its components."

What is "obscured" it the protection methods, not the secured object
as such.
Arne Vajhøj
2020-11-12 13:20:35 UTC
Reply
Permalink
Post by Dave Froble
Post by Arne Vajhøj
Post by Dave Froble
Post by Alexander Schreiber
Post by seasoned_geek
ALL
ENCRYPTION is security by obscurity. Period.
Thus proving nicely that you know _absolutely_ nothing about encryption.
You imight want to read up on Kerckhoff's principle for starters.
Well, I wouldn't be so quick to dismiss that statement.
Isn't not knowing a solution a form of obscurity?  Otherwise, if one
knows the key, then there is no security, right?  So not knowing the
key is sort of "security by obscurity"?
There have been multiple instances in the past of codes being broken
and harmful affects because of that.  The Japanese code in WWII?
What is a "secret key", other than "unknown data"?  Can such a key be
guessed?  Unlikely.  But possible.
Security by obscurity has a very specific meaning.
That's kind of narrow thinking, isn't it?
It is the standard terminology.
Post by Dave Froble
Post by Arne Vajhøj
It is when the security depends on the algorithm being kept secret.
This is generally considered bad.
And none of the standard algorithms today use it.
You can open any text book on encryption and see the algorithms
for AES, RSA etc. and they are still prohibitively difficult
to crack.
AES 256 bit has a 256 bit key. That is 2 power 256 possible keys.
That is a big number.
I agree with all that, but, the statement seems to still apply, at least
to me.  If one doesn't know how to access, then, it is obscure, or by
the statement, unknown, right?
I a not sure that I can follow you.

AES consist of two things: algorithm and key.

Algorithm is a description of a mathematical transformation of
data. It is constant across all usage. It is public.

Key is data aka a number of bytes. It is different between
usages. It is secret.

The definition of security by obscurity is that the security depends
on the algorithm to be kept secret.

AES does not reply on the algorithm being secret. In fact it is widely
known.


So AES is not security by obscurity.

Arne
seasoned_geek
2020-11-20 14:46:50 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by seasoned_geek
ALL
ENCRYPTION is security by obscurity. Period.
Security by obscurity has a very specific meaning.
It is when the security depends on the algorithm being kept secret.
You need to search for and watch a very short George Carlin video discussing the18th century definition of the f-word. It's on You-tube.

"tap with a stick"

To people who are asked by clients to look at this stuff "Security by obscurity" means chanting the mantra "no known vulnerabilities" and bragging about the size of the forest you are about to hide a tree in.

It depends on people not knowing truth and wanting to believe something is true. Poke around in the "Hidden Brain" podcasts for the one covering how people are more apt to believe something completely false without ever verifying it if it supports something they already believe to be true or wish to be true.

People don't search for truth, they search for things that support their opinion. On rare ocassions they ask someone like me to blue-sky how their opinion screwed them.
Post by Arne Vajhøj
You can open any text book on encryption and see the algorithms
for AES, RSA etc. and they are still prohibitively difficult
to crack.
And honestly, that has less than zero to do with this conversation than you are capable of realizing.

This entire conversations started what now feels like a lifetime ago in my Qt circles on TLS/SSL. People on PC platforms are even more gullible when it comes to believing in one-and-done security than midrange. People chanting they were "secure" because they used SSL/TLS.

https://www.cloudinsidr.com/content/known-attack-vectors-against-tls-implementation-vulnerabilities/

I'm not going to put an extreme search effort into it, but if you poke on-line you will find a link explaining how a Ubuntu "maintainer" helped out the upstream developers cleaning up a compilation warning that then limited all values to 32-bit. What is printed in the book, doesn't matter.This was out there a long time. It impacted every YABU distro, many of which are used for servers in financial transactions.

Prior to life really changing this year, I purchased a 4TB WD black drive to set up a database on because it looked like, testing with the command line tool, there was a severe TOD sensitivity on Ubuntu 18.04 as well. I did not get around to writing the code to generate the database.

I wanted to prove the TOD sensitivity then we could dig in to see if this was introduced by AGILE software development, inept programmer (which AGILE pretty-much indicates) or a compiler introduced issue. Here is a really long and boring read on some of the compiler introduced vulnerabilities.

https://arc.aiaa.org/doi/10.2514/1.I010699
Post by Arne Vajhøj
AES 256 bit has a 256 bit key. That is 2 power 256 possible keys.
That is a big number.
Size of the forest where you are hiding a tree. Completely ignoring the fact the tree you are hiding is a Redwood and the forest you are using is in Wisconsin.

Not in today's world. Not for people who are asked to think about such things. Not for someone looking to hit a single specific target.

Myth #1 of security: A hacker needs everything

No. You don't. If you want to avoid getting caught the longest you can, you well and truly don't want everything. All you really need is "sniffing" access along a feeder and some general public knowledge.

Before you try and spin this into one of your academic imaginary worlds where only you exist, I haven't thought about this in a long time. Winging from memory rather than bothering to look up. The scenario was, as I recall,

1) published XML standard being used
2) single message containing the short XML transaction (like a CC request for authorization)
3) SALT
There was some other piece here that is in my notes on another machine and archived in a long discussion elsewhere.

You know for a fact the message starts with:
<?xml version="1.0" encoding="UTF-8"?>
to be safe you can stop with just: <?xml version="

When the SALT has a TOD sensitivity such that between 2pm and 4pm local time only the last 5 really change (what I had stumbled into with some casual testing) you now only need the password. You know, that's not as difficult as it sounds given the helpful pages like this:
https://help.pearsoncmg.com/rumba/b2c_self_reg/en/Content/b2c_signin_guidelines.html
scattered all around the Internet and most certainly there will be one for your target. On that page you will find a section worded much like this:

======
Password

Your password:

Must be between eight and 32 characters long.
Must include at least one number or special character and one letter.
Can contain any letters a to z and any numbers from 0 through 9.
Can contain some special characters, including @ (at sign) . (period) - (hyphen or dash) _ (underscore).
Cannot contain spaces or non-English characters (such as é).
Is case-sensitive.
Must be different from your first name, last name, and username.

======

I now have all I really need to put my little BOT-NET to work generating entries for a PostgreSQL database. Each table will be named based on the SALT value. Each BOT is given a very simple task.
"Take this list of 100 valid generated passwords using this SALT value and encrypt <?xml version= returning the result for each."
That's it. Once per hour each of your hundreds or thousands of bots gets a tiny packet, possibly less than 1K in size. It does an imperceptibly small amount of calculations and returns, possibly 2K. If you have identified that between 2-4pm the generated SALT will only very within the last 5-digits you now just have 99,999 tables. The password rules mean you don't have all permutations of 32 characters, just a severely limited subset. You are searching for the pre-amble of __exactly__ one known message. The side effect is you _can_ now decrypt every other single XML packet you happen to sniff.

Operation one just builds the database. It gets better over time. How much time depends on how many BOTS you have and how heavy you want to load them.
Operation two is the sniffer. It wakes up near 2pm and shuts down near 4pm. Btw, there was nothing magic about 2-4pm, it was just what I was trying. You could most likely use 7-9am if you wanted people buying coffee, gas, etc. on the way to work.

Operation three receives the sniffed packets and does a partial keyed hit of the encrypted data to the table for the SALT. Upon match it decrypts the packet and routes it to another step that does some more verification before involving a human. If you are low budget and low tech, perhaps you send it straight to a human?
This is very doable today I believe. I simply have too much going on in life to devote a bunch of non-billed effort into it. Storage is certainly getting really cheap - assuming you don't want to pay some hosting service for a 100 TB you can get a "portable" (perhaps with two guys carrying it) 32TB NAS for under $2500.
https://www.newegg.com/p/14P-001N-00010?Description=32tb%20nas&cm_re=32tb_nas-_-14P-001N-00010-_-Product&quicklink=true

Each "record" in each table only has the VARCHAR password and the VARCHAR target encrypted output. Given the previous example that means 32 or fewer characters for the password (many probably closer to eight). What? At most another 32 characters for the target which will be the alternate key? You don't even need a big BOT-NET, just time.

The database can even be "rented out" to evil doers. If the packet has a pure XML message started with the universal beginning and has a SALT within range, it has a high probability of cracking it with a single keyed hit.
Now. I have spent far too long on this. I really have to get on with what I'm supposed to be doing today.

Far too many people in IT try to hide a Redwood in Wisconsin.
Believe it or not; a large number of transactions on the Web are just one XML object in a "secured" packet.
Arne Vajhøj
2020-11-21 00:59:50 UTC
Reply
Permalink
Post by seasoned_geek
Before you try and spin this into one of your academic imaginary worlds where only you exist, I haven't thought about this in a long time. Winging from memory rather than bothering to look up. The scenario was, as I recall,
1) published XML standard being used
2) single message containing the short XML transaction (like a CC request for authorization)
3) SALT
There was some other piece here that is in my notes on another machine and archived in a long discussion elsewhere.
<?xml version="1.0" encoding="UTF-8"?>
to be safe you can stop with just: <?xml version="
Actually you can't.

Your approach requires a full block which is 16 bytes for AES.
Symmetric encryption use IV not salt.

And with a decent implementation all bytes should change.
Post by seasoned_geek
Password
Must be between eight and 32 characters long.
Must include at least one number or special character and one letter.
Can contain any letters a to z and any numbers from 0 through 9.
Cannot contain spaces or non-English characters (such as é).
Is case-sensitive.
Must be different from your first name, last name, and username.
======
Which is pretty irrelevant since password is not used as key for
encrypting traffic in standard protocols.
Post by seasoned_geek
I now have all I really need to put my little BOT-NET to work
generating entries for a PostgreSQL database. Each table will be
named based on the SALT value. Each BOT is given a very simple task.
"Take this list of 100 valid generated passwords using this SALT
value and encrypt <?xml version= returning the result for each."
That's it. Once per hour each of your hundreds or thousands of bots
gets a tiny packet, possibly less than 1K in size. It does an
imperceptibly small amount of calculations and returns, possibly 2K.
If you have identified that between 2-4pm the generated SALT will
only very within the last 5-digits you now just have 99,999 tables.
The password rules mean you don't have all permutations of 32
characters, just a severely limited subset. You are searching for the
pre-amble of __exactly__ one known message. The side effect is you
_can_ now decrypt every other single XML packet you happen to sniff.
Operation one just builds the database. It gets better over time. How
much time depends on how many BOTS you have and how heavy you want to
load them. Operation two is the sniffer. It wakes up near 2pm and
shuts down near 4pm. Btw, there was nothing magic about 2-4pm, it was
just what I was trying. You could most likely use 7-9am if you wanted
people buying coffee, gas, etc. on the way to work.
Operation three receives the sniffed packets and does a partial keyed
hit of the encrypted data to the table for the SALT. Upon match it
decrypts the packet and routes it to another step that does some more
verification before involving a human. If you are low budget and low
tech, perhaps you send it straight to a human? This is very doable
today I believe. I simply have too much going on in life to devote a
bunch of non-billed effort into it. Storage is certainly getting
really cheap - assuming you don't want to pay some hosting service
for a 100 TB you can get a "portable" (perhaps with two guys carrying
it) 32TB NAS for under $2500.
https://www.newegg.com/p/14P-001N-00010?Description=32tb%20nas&cm_re=32tb_nas-_-14P-001N-00010-_-Product&quicklink=true
Each "record" in each table only has the VARCHAR password and the
VARCHAR target encrypted output. Given the previous example that
means 32 or fewer characters for the password (many probably closer
to eight). What? At most another 32 characters for the target which
will be the alternate key? You don't even need a big BOT-NET, just
time.
But since HTTPS and SSL in general does not work as you describe, then
it is rather pointless.
Post by seasoned_geek
Believe it or not; a large number of transactions on the Web are just one XML object in a "secured" packet.
They are not.

Before the XML in the body comes all the HTTP headers.

And those are also encrypted.

Arne
Arne Vajhøj
2020-11-21 01:10:30 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by seasoned_geek
When the SALT has a TOD sensitivity such that between 2pm and 4pm
local time only the last 5 really change (what I had stumbled into
with some casual testing) you now only need the password. You know,
Symmetric encryption use IV not salt.
And with a decent implementation all bytes should change.
And if anyone want to verify that it does.

Just do:

$ mcr ssl1$exe:openssl enc -aes-256-cbc -k MySuperSecretPassPhrase -P
-md sha1

on your favorite OS a few times.

I got:

iv =0E38C5B4A04DAD98965D95161268ECDB
iv =51D9A670DEB1BF1E56745D28A6441A3C
iv =26E6C8F59628C12A7A4EBFC3BF340727
iv =E4609B2D4AFD0B8190101A87F8CA83DB
iv =9350E05D92C0915B229048B251E3C663

They look quite different to me.

Arne
seasoned_geek
2020-11-21 01:23:43 UTC
Reply
Permalink
Post by Arne Vajhøj
$ mcr ssl1$exe:openssl enc -aes-256-cbc -k MySuperSecretPassPhrase -P
-md sha1
on your favorite OS a few times.
iv =0E38C5B4A04DAD98965D95161268ECDB
iv =51D9A670DEB1BF1E56745D28A6441A3C
iv =26E6C8F59628C12A7A4EBFC3BF340727
iv =E4609B2D4AFD0B8190101A87F8CA83DB
iv =9350E05D92C0915B229048B251E3C663
They look quite different to me.
And once again, arne, knowing less than nothing about what was asked chooses to try to spin something into his microscopic universe. I had SALT in all upper case because that is what was asked about.

Whatever toilet you wish to swim in is irrelevant to the conversation. It wasn't what was asked. It isn't what is in use.
Arne Vajhøj
2020-11-21 01:37:21 UTC
Reply
Permalink
Post by seasoned_geek
Post by Arne Vajhøj
$ mcr ssl1$exe:openssl enc -aes-256-cbc -k MySuperSecretPassPhrase
-P -md sha1
on your favorite OS a few times.
iv =0E38C5B4A04DAD98965D95161268ECDB iv
=51D9A670DEB1BF1E56745D28A6441A3C iv
=26E6C8F59628C12A7A4EBFC3BF340727 iv
=E4609B2D4AFD0B8190101A87F8CA83DB iv
=9350E05D92C0915B229048B251E3C663
They look quite different to me.
And once again, arne, knowing less than nothing about what was asked
chooses to try to spin something into his microscopic universe. I had
SALT in all upper case because that is what was asked about.
AES (and other block cipher symmetric encryption) only use
key and iv (not using iv in ECB mode, but nobody should
use ECB mode). No salt. Or SALT (which is usually considered an
abbreviation for some USA-USSR treaties a long time ago).

So if you want to attempt your tabulation trick, then
you need to deal with key and iv.

And iv changes more than last 5 as demonstrated above.

So your tabulation trick does not work.

Arne

PS: It can use salt when generating keys but that is another matter
and does not influence the problem of a 256 bit random iv.
seasoned_geek
2020-11-21 09:19:27 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by seasoned_geek
Post by Arne Vajhøj
$ mcr ssl1$exe:openssl enc -aes-256-cbc -k MySuperSecretPassPhrase
-P -md sha1
on your favorite OS a few times.
iv =0E38C5B4A04DAD98965D95161268ECDB iv
=51D9A670DEB1BF1E56745D28A6441A3C iv
=26E6C8F59628C12A7A4EBFC3BF340727 iv
=E4609B2D4AFD0B8190101A87F8CA83DB iv
=9350E05D92C0915B229048B251E3C663
They look quite different to me.
And once again, arne, knowing less than nothing about what was asked
chooses to try to spin something into his microscopic universe. I had
SALT in all upper case because that is what was asked about.
AES (and other block cipher symmetric encryption) only use
key and iv (not using iv in ECB mode, but nobody should
use ECB mode). No salt. Or SALT (which is usually considered an
abbreviation for some USA-USSR treaties a long time ago).
So if you want to attempt your tabulation trick, then
you need to deal with key and iv.
And iv changes more than last 5 as demonstrated above.
So your tabulation trick does not work.
You demonstrated NOTING above. You completely ignored everything relevant (as usual).

The problem was noticed on Ubuntu 18.04 LTS. It might still exist in 20.04 LTS because I haven't read about any fixes for it per-se.

How do you think the other YABU specific problem was found? The one where someone "fixed a compilation warning" and limited the calculations to 32-bits? Tabulation. The min and the max after hours/days/weeks of running never exceeded a 32-bit range.

Please. Never ever comment on my posts. You never actually read and simply don't know anything.
Arne Vajhøj
2020-11-21 13:23:00 UTC
Reply
Permalink
Post by seasoned_geek
Post by seasoned_geek
Post by Arne Vajhøj
$ mcr ssl1$exe:openssl enc -aes-256-cbc -k
MySuperSecretPassPhrase -P -md sha1
on your favorite OS a few times.
iv =0E38C5B4A04DAD98965D95161268ECDB iv
=51D9A670DEB1BF1E56745D28A6441A3C iv
=26E6C8F59628C12A7A4EBFC3BF340727 iv
=E4609B2D4AFD0B8190101A87F8CA83DB iv
=9350E05D92C0915B229048B251E3C663
They look quite different to me.
And once again, arne, knowing less than nothing about what was
asked chooses to try to spin something into his microscopic
universe. I had SALT in all upper case because that is what was
asked about.
AES (and other block cipher symmetric encryption) only use key and
iv (not using iv in ECB mode, but nobody should use ECB mode). No
salt. Or SALT (which is usually considered an abbreviation for some
USA-USSR treaties a long time ago).
So if you want to attempt your tabulation trick, then you need to
deal with key and iv.
And iv changes more than last 5 as demonstrated above.
So your tabulation trick does not work.
The problem was noticed on Ubuntu 18.04 LTS. It might still exist in
20.04 LTS because I haven't read about any fixes for it per-se.
That should be pretty easy to check - just give us the CVE and
we can see when it was fixed.

Arne

seasoned_geek
2020-11-21 09:14:47 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by Arne Vajhøj
And with a decent implementation all bytes should change.
And if anyone want to verify that it does.
$ mcr ssl1$exe:openssl enc -aes-256-cbc -k MySuperSecretPassPhrase -P
-md sha1
on your favorite OS a few times.
iv =0E38C5B4A04DAD98965D95161268ECDB
iv =51D9A670DEB1BF1E56745D28A6441A3C
iv =26E6C8F59628C12A7A4EBFC3BF340727
iv =E4609B2D4AFD0B8190101A87F8CA83DB
iv =9350E05D92C0915B229048B251E3C663
They look quite different to me.
You know Arne, some people shouldn't be allowed to buy a keyboard and you are one. Once again you have veered off into the weeds ignoring details that didn't fit into your tiny mind.

NONE of this has __anything__ to do with what I originally stated about SSL/TLS having a TOD sensitivity on Ubuntu. In particular I noticed it on 18.04 but it might also exist in 20.04 LTS, I just haven't had time to look into it.

Guess what? When the "maintainer" decided to "help out the upstream" some years back by cleaning up that compilation warning, only YABUs had a 32-bit limit. You couldn't replicate that problem on VMS either.

I have asked you repeatedly to never comment on my messages because you know less than nothing and READ EVEN LESS.
Arne Vajhøj
2020-11-21 13:14:14 UTC
Reply
Permalink
Post by seasoned_geek
Post by Arne Vajhøj
On 11/20/2020 9:46 AM, seasoned_geek wrote: And with a decent
implementation all bytes should change.
And if anyone want to verify that it does.
$ mcr ssl1$exe:openssl enc -aes-256-cbc -k MySuperSecretPassPhrase
-P -md sha1
on your favorite OS a few times.
iv =0E38C5B4A04DAD98965D95161268ECDB iv
=51D9A670DEB1BF1E56745D28A6441A3C iv
=26E6C8F59628C12A7A4EBFC3BF340727 iv
=E4609B2D4AFD0B8190101A87F8CA83DB iv
=9350E05D92C0915B229048B251E3C663
They look quite different to me.
NONE of this has __anything__ to do with what I originally stated
about SSL/TLS having a TOD sensitivity on Ubuntu. In particular I
noticed it on 18.04 but it might also exist in 20.04 LTS, I just
haven't had time to look into it.
Same command on Ubuntu 18.04 gives me:

iv =DBC516ED25201B36D36D72AFF00DFCDE

iv =A96AA6C6108F5CB463866EF6ECF87B66

iv =225EF75D2BDB0D89580287DC212B3C61

iv =F691ECE8B2A294E6376792CD286C6A93

iv =241D4F17A1FD7B1AE4BA1CD2A6F74856

Arne
Alexander Schreiber
2020-11-16 00:13:28 UTC
Reply
Permalink
Post by Dave Froble
Post by Alexander Schreiber
Post by seasoned_geek
ALL
ENCRYPTION is security by obscurity. Period.
Thus proving nicely that you know _absolutely_ nothing about encryption.
You imight want to read up on Kerckhoff's principle for starters.
Well, I wouldn't be so quick to dismiss that statement.
Isn't not knowing a solution a form of obscurity? Otherwise, if one
knows the key, then there is no security, right? So not knowing the key
is sort of "security by obscurity"?
There have been multiple instances in the past of codes being broken and
harmful affects because of that. The Japanese code in WWII?
What is a "secret key", other than "unknown data"? Can such a key be
guessed? Unlikely. But possible.
Would it be too much to read up at least _some_ on encryption? One
fundamental property of a _good_ encryption algorithm is that it stands
up to Kerckhoffs Principle: even if the attacker knows everything about
the design of the cryptosystem, it is still secure as long as the
keys are not known to the attacker - which is a derivations of Shannons
"the enemy knows the system" principle.
Good current algorithms like AES have this property - brute force cracking
(trying all keys) takes an entirely uselessly long amount of time and there
are currently no know weaknesses that reduce this time to something useful
(e.g. days or weeks). DES died because at the latest with Deep Crack a
DES brute force key cracking machine was available that scaled linearly
with the money thrown at it - making almost-realtime (days to hours to
minutes) cracking of DES keys possible depending on budget.

Yes, that means exchanging keys between trusted parties so that the
attacker doesn't get to know them is it's own thorny problem, but
there _are_ various solution to that.

Relying on the attacker _not_ knowing the system means you fundamentally
rely on your attacker being stupid and _that_ is a very bold strategy.

Kind regards,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
Dave Froble
2020-11-16 06:05:44 UTC
Reply
Permalink
Post by Alexander Schreiber
Post by Dave Froble
Post by Alexander Schreiber
Post by seasoned_geek
ALL
ENCRYPTION is security by obscurity. Period.
Thus proving nicely that you know _absolutely_ nothing about encryption.
You imight want to read up on Kerckhoff's principle for starters.
Well, I wouldn't be so quick to dismiss that statement.
Isn't not knowing a solution a form of obscurity? Otherwise, if one
knows the key, then there is no security, right? So not knowing the key
is sort of "security by obscurity"?
There have been multiple instances in the past of codes being broken and
harmful affects because of that. The Japanese code in WWII?
What is a "secret key", other than "unknown data"? Can such a key be
guessed? Unlikely. But possible.
Would it be too much to read up at least _some_ on encryption? One
fundamental property of a _good_ encryption algorithm is that it stands
up to Kerckhoffs Principle: even if the attacker knows everything about
the design of the cryptosystem, it is still secure as long as the
keys are not known to the attacker - which is a derivations of Shannons
"the enemy knows the system" principle.
Good current algorithms like AES have this property - brute force cracking
(trying all keys) takes an entirely uselessly long amount of time and there
are currently no know weaknesses that reduce this time to something useful
(e.g. days or weeks). DES died because at the latest with Deep Crack a
DES brute force key cracking machine was available that scaled linearly
with the money thrown at it - making almost-realtime (days to hours to
minutes) cracking of DES keys possible depending on budget.
Yes, that means exchanging keys between trusted parties so that the
attacker doesn't get to know them is it's own thorny problem, but
there _are_ various solution to that.
Relying on the attacker _not_ knowing the system means you fundamentally
rely on your attacker being stupid and _that_ is a very bold strategy.
Kind regards,
Alex.
I think you misunderstand me.

I'm not saying that an attacker doesn't know the algorithm, I'm saying
the attacker does not know the secret key. But, however unlikely, an
attacker could "guess" the secret key on his first try. It is the fact
that an attacker doesn't know the secret key is the "obscurity" aspect
of the security. Since an attacker could get incredibly lucky and guess
the secret key on his first attempt, then it is only the difficult of
that guess that is the security.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Phillip Helbig (undress to reply)
2020-11-16 08:38:40 UTC
Reply
Permalink
Post by Dave Froble
I'm not saying that an attacker doesn't know the algorithm, I'm saying
the attacker does not know the secret key. But, however unlikely, an
attacker could "guess" the secret key on his first try. It is the fact
that an attacker doesn't know the secret key is the "obscurity" aspect
of the security. Since an attacker could get incredibly lucky and guess
the secret key on his first attempt, then it is only the difficult of
that guess that is the security.
Right. I think that folks here understand. However, the term "security
by obscurity" has a very specific meaning, and it is confusing to use it
to mean something else.

By your definition, all forms of access restriction are "security by
obscurity", since those who have access have it because they have
something which those who don't don't, though they could, theoretically,
bluff their way through and get lucky.
Dave Froble
2020-11-16 14:32:44 UTC
Reply
Permalink
Post by Phillip Helbig (undress to reply)
Post by Dave Froble
I'm not saying that an attacker doesn't know the algorithm, I'm saying
the attacker does not know the secret key. But, however unlikely, an
attacker could "guess" the secret key on his first try. It is the fact
that an attacker doesn't know the secret key is the "obscurity" aspect
of the security. Since an attacker could get incredibly lucky and guess
the secret key on his first attempt, then it is only the difficult of
that guess that is the security.
Right. I think that folks here understand. However, the term "security
by obscurity" has a very specific meaning, and it is confusing to use it
to mean something else.
By your definition, all forms of access restriction are "security by
obscurity", since those who have access have it because they have
something which those who don't don't, though they could, theoretically,
bluff their way through and get lucky.
I was just agreeing with Roland's statement, "ALL ENCRYPTION is security
by obscurity".
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Bill Gunshannon
2020-11-16 14:46:26 UTC
Reply
Permalink
Post by Dave Froble
Post by Dave Froble
I'm not saying that an attacker doesn't know the algorithm, I'm saying
the attacker does not know the secret key.  But, however unlikely, an
attacker could "guess" the secret key on his first try.  It is the fact
that an attacker doesn't know the secret key is the "obscurity" aspect
of the security.  Since an attacker could get incredibly lucky and guess
the secret key on his first attempt, then it is only the difficult of
that guess that is the security.
Right.  I think that folks here understand.  However, the term "security
by obscurity" has a very specific meaning, and it is confusing to use it
to mean something else.
By your definition, all forms of access restriction are "security by
obscurity", since those who have access have it because they have
something which those who don't don't, though they could, theoretically,
bluff their way through and get lucky.
I was just agreeing with Roland's statement, "ALL ENCRYPTION is security
by obscurity".
You can redefine a term common to the IT world all you want, it
does not change reality.

bill
Dave Froble
2020-11-16 14:52:28 UTC
Reply
Permalink
Post by Bill Gunshannon
Post by Dave Froble
Post by Phillip Helbig (undress to reply)
Post by Dave Froble
I'm not saying that an attacker doesn't know the algorithm, I'm saying
the attacker does not know the secret key. But, however unlikely, an
attacker could "guess" the secret key on his first try. It is the fact
that an attacker doesn't know the secret key is the "obscurity" aspect
of the security. Since an attacker could get incredibly lucky and guess
the secret key on his first attempt, then it is only the difficult of
that guess that is the security.
Right. I think that folks here understand. However, the term "security
by obscurity" has a very specific meaning, and it is confusing to use it
to mean something else.
By your definition, all forms of access restriction are "security by
obscurity", since those who have access have it because they have
something which those who don't don't, though they could, theoretically,
bluff their way through and get lucky.
I was just agreeing with Roland's statement, "ALL ENCRYPTION is
security by obscurity".
You can redefine a term common to the IT world all you want, it
does not change reality.
bill
My language is English, not Geek ....
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
seasoned_geek
2020-11-20 15:46:42 UTC
Reply
Permalink
Right. I think that folks here understand. However, the term "security
by obscurity" has a very specific meaning, and it is confusing to use it
to mean something else.
No. The term "security by obscurity" currently has an obsolete definition. Technically it has always had an obsolete definition, even from day one. You can journey through all of the encryption methods that "would take a super computer years to crack" which are now no longer used because they are child's play. According to some computer history sites a Cray-1 could do 160 MIPS. An i7 920 (Quadcore) can do 82,300 MIPS. According to Wikipedia (not a reliable source) https://en.wikipedia.org/wiki/List_of_Intel_Core_i7_microprocessors it was released in November 2008.

I have yet to find _any_ encryption method which was not relying on the size of the forest one wanted to hide a tree in.
I have yet to find a champion of said methods who doesn't believe the hacker has to have everything to get my one message.

Those are both very outdated modes of thinking.

When one does the math: considering a 6+ million BOT-NET of i7 920 or above computers (given their age, not unreasonable) You could even go back to 4th gen i5 if you want. https://ark.intel.com/content/www/us/en/ark/products/series/75024/4th-generation-intel-core-i5-processors.html all running at the don't notice it pace of processing 1 packet per hour containing 100 passwords to generate output from and the single SALT to use; it's easy to see a massive amount of data being put into a database over the course of a week.

Hackers don't need _everything_. The need many things for one known packet pre-amble. That universal XML opening text. If they can penetrate even 1% of the CC request for authorization transactions and get valid data to use for another authorization paying money to them or buying products to resell, it's profitable.
By your definition, all forms of access restriction are "security by
obscurity", since those who have access have it because they have
something which those who don't don't, though they could, theoretically,
bluff their way through and get lucky.
This has always been the case. People pilfer an employee security badge to get access to a building or a room. People talk their way through a door. That's spy craft 101.

We have all watched television shows where someone picked a lock. You can buy the tools and a practice lock in a clear block online. Even if you have the best steel door on your home/office, the key lock is the way in. Most people don't have that. They have a door that looks "nice." That means the lock is really only there to keep out honest people because a solid enough guy can kick/force their way through it.
Arne Vajhøj
2020-11-21 00:12:36 UTC
Reply
Permalink
Post by seasoned_geek
Right. I think that folks here understand. However, the term "security
by obscurity" has a very specific meaning, and it is confusing to use it
to mean something else.
No. The term "security by obscurity" currently has an obsolete definition. Technically it has always had an obsolete definition, even from day one.
You don't seem to understand what terminology is.

Terminology describe the terms actually used to facilitate
communication.

The term "security by obscurity" is used today with a certain
meaning.

That you want to use a different definition is similar to wanting
to change the meaning of North and South. Sure you can switch them
around, but it as long as everybody else is using the common
meaning, then it would be pointless.

Arne
seasoned_geek
2020-11-21 01:04:51 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by seasoned_geek
Right. I think that folks here understand. However, the term "security
by obscurity" has a very specific meaning, and it is confusing to use it
to mean something else.
No. The term "security by obscurity" currently has an obsolete definition. Technically it has always had an obsolete definition, even from day one.
You don't seem to understand what terminology is.
Terminology describe the terms actually used to facilitate
communication.
The term "security by obscurity" is used today with a certain
meaning.
That you want to use a different definition is similar to wanting
to change the meaning of North and South. Sure you can switch them
around, but it as long as everybody else is using the common
meaning, then it would be pointless.
Again, only a token few here cling to the archaic definition. You also didn't look up and watch the definition of the F-word.

The terminology was always incorrect.

It's much like imbeciles claiming hacking on the fly is software engineering when you call it AGILE. They are wrong, but they are also unteachable.
Phillip Helbig (undress to reply)
2020-11-21 05:57:53 UTC
Reply
Permalink
Post by Arne Vajhøj
You don't seem to understand what terminology is.
Terminology describe the terms actually used to facilitate
communication.
The term "security by obscurity" is used today with a certain
meaning.
That you want to use a different definition is similar to wanting
to change the meaning of North and South. Sure you can switch them
around, but it as long as everybody else is using the common
meaning, then it would be pointless.
Seriously, Lewis Carroll wrote an entire chapter on this.
seasoned_geek
2020-11-21 09:25:32 UTC
Reply
Permalink
Post by Phillip Helbig (undress to reply)
Post by Arne Vajhøj
You don't seem to understand what terminology is.
Terminology describe the terms actually used to facilitate
communication.
The term "security by obscurity" is used today with a certain
meaning.
That you want to use a different definition is similar to wanting
to change the meaning of North and South. Sure you can switch them
around, but it as long as everybody else is using the common
meaning, then it would be pointless.
Seriously, Lewis Carroll wrote an entire chapter on this.
Chapter?

https://www.bartleby.com/73/2019.html

Wow! That was a very "Warehouse 13" moment.
seasoned_geek
2020-11-20 15:19:00 UTC
Reply
Permalink
Post by Alexander Schreiber
Would it be too much to read up at least _some_ on encryption? One
fundamental property of a _good_ encryption algorithm is that it stands
up to Kerckhoffs Principle: even if the attacker knows everything about
the design of the cryptosystem, it is still secure as long as the
keys are not known to the attacker - which is a derivations of Shannons
"the enemy knows the system" principle.
The real problem with reading up on it is it leads people to be lulled into a false sense of security. That there really is a one-and-done solution. It also leads to people chanting the mantra "no known security vulnerabilities".
Post by Alexander Schreiber
Good current algorithms like AES have this property - brute force cracking
(trying all keys) takes an entirely uselessly long amount of time and there
are currently no know weaknesses that reduce this time to something useful
Bingo! <to quote Dave>

Again, see the very long response to Arne.

Every false sense of IT security is based on the false belief that a hacker needs or wants absolutely everything. One of the re reasons CC fraud is so rampant is that belief being patently false. They have progressed to the point of charging a few hundred dollars and moving on.

It doesn't matter how perfect the algorithm seems on paper. Compiler optimization introduces issues. AGILE (and by definition low quality) developers fail to understand said algorithm and implement something that only passes the tests they write. Maintenance developers, like the Ubuntu maintainer who decided to "help out upstream" by getting rid of a compilation warning reduce a critical variable to 32-bits in size.

All of this makes the grand assumption the attacker is trying to get in and the even grander assumption they have to know everything because they don't know what they are looking for.

When they are just sniffing packets (collecting echoes really) of authorization request packages being routed to a merchant/cc processor, they are just looking to crack _some_ of them. Fraud investigators try to identify breaches based on shopping patterns of the victims. When they are scattered around the country at different merchants it makes it really difficult; especially when the forensics of the Merchant/CC processor system turn up clean and everyone working there passes a polygraph.

The big business of CC fraud has simply backed into the answer they need like mathematicians back into answers to problems they cannot solve. Instead of saying
"I know the SALT and I know it is an XML packet, but I can't solve for X (the password)" like most gullible enough to believe encryption is secure they appear (at least in my thinking) to have taken the pragmatic approach.

1) "<?xml version=" is at the beginning of every packet I'm interested in.
2) I know the rules for the passwords so it is not every permutation of 32 characters, rather it is a significantly limited subset. Most will be the minimum 8 and definitely under 20 because people hate typing as well as coming up with new passwords. Many people end their passwords with "_n" where n is a number because far too many financial institutions make them change it every month or 60 days so this way they can just increment a number.
3) If I can find a time frame where the generated SALT is a lot less random I can build a rather complete database over time.
4) If I happen to be one of these bot-nets: https://themerkle.com/top-4-largest-botnets-to-date/ my only real problem is the storage I/O. 6+ million bots generating 100 entries per hour each will fill a 32TB NAS up pretty fast. I will need 20-30 of them scattered around the globe. Gee! I guess I will buy them with a stolen CC or 40!

Brute force has gone off-line and high tech.
Arne Vajhøj
2020-11-21 00:34:40 UTC
Reply
Permalink
Post by seasoned_geek
Post by Alexander Schreiber
Good current algorithms like AES have this property - brute force
cracking (trying all keys) takes an entirely uselessly long amount
of time and there are currently no know weaknesses that reduce this
time to something useful
The big business of CC fraud has simply backed into the answer they
need like mathematicians back into answers to problems they cannot
solve. Instead of saying "I know the SALT and I know it is an XML
packet, but I can't solve for X (the password)" like most gullible
enough to believe encryption is secure they appear (at least in my
thinking) to have taken the pragmatic approach.
1) "<?xml version=" is at the beginning of every packet I'm
interested in. 2) I know the rules for the passwords so it is not
every permutation of 32 characters, rather it is a significantly
limited subset. Most will be the minimum 8 and definitely under 20
because people hate typing as well as coming up with new passwords.
Many people end their passwords with "_n" where n is a number because
far too many financial institutions make them change it every month
or 60 days so this way they can just increment a number. 3) If I can
find a time frame where the generated SALT is a lot less random I can
build a rather complete database over time. 4) If I happen to be one
https://themerkle.com/top-4-largest-botnets-to-date/ my only real
problem is the storage I/O. 6+ million bots generating 100 entries
per hour each will fill a 32TB NAS up pretty fast. I will need 20-30
of them scattered around the globe. Gee! I guess I will buy them with
a stolen CC or 40!
Brute force has gone off-line and high tech.
This not how encryption is used today.

Symmetric encryption do not use salt but use initialization vector (IV),
but let us ignore that terminology matter.

What you basically is saying is that encryption:
* with known plain text (XML prologue) in first block
* an IV with very limited range
* a key that is deterministically derived from only
a human picked weak password
can be brute forced.

It most certainly can. It may not even be necessary to tabulate it.

For 8 character passwords it is really a 48 bit encryption
aka a lot weaker than DES from the 1970's. And a limited
range IV can not prevent tabulation - and can certainly
not prevent direct brute force.

But it has not much to do with how encryption is
used today.

The XML prologue is usually not the first block as it
is preceded with various headers.

IV is generated with a pseudo random number generator
and have full range.

Key is either generated with a cryptographic secure pseudo
random number generator and exchanged via asymmetric encryption
or derived from a long passphrase to ensure full
128/192/256 bit entropy.

With a full range 256 bit IV and a key with 128/192/256 bit
entropy then tabulation will not work.

Arne
seasoned_geek
2020-11-21 01:09:11 UTC
Reply
Permalink
Post by Arne Vajhøj
This not how encryption is used today.
Symmetric encryption do not use salt but use initialization vector (IV),
but let us ignore that terminology matter.
You know arne. Thanks for proving once again you should never be allowed near a keyboard. You have no idea about what the conversation is or about what a client asked (and continues to ask periodically) yet you continue to speak out your lower mouth about it.
Arne Vajhøj
2020-11-21 01:19:31 UTC
Reply
Permalink
Post by seasoned_geek
Post by Arne Vajhøj
On Sunday, November 15, 2020 at 7:08:10 PM UTC-6, Alexander
This not how encryption is used today.
Symmetric encryption do not use salt but use initialization vector
(IV), but let us ignore that terminology matter.
You know arne. Thanks for proving once again you should never be
allowed near a keyboard. You have no idea about what the conversation
is or about what a client asked (and continues to ask periodically)
yet you continue to speak out your lower mouth about it.
You may have client that want to call it salt.

But to the world it is called IV.

See documentation like NIST 800-38A or API's
like OpenSSL EVP_*Init_ex.

Arne
seasoned_geek
2020-11-21 01:30:42 UTC
Reply
Permalink
Post by Arne Vajhøj
Symmetric encryption do not use salt but use initialization vector (IV),
but let us ignore that terminology matter.
But it has not much to do with how encryption is
used today.
The XML prologue is usually not the first block as it
is preceded with various headers.
You know arne, some day you will stop talking out your arse. That will be the day 3-contintents disappear into the ocean.

You have zero idea what was asked by a client and less than zero idea what is happening in their Internet transactions. They have a SALT. That is why I put it in upper case. For a goodly number of their transactions the XML protocol is the first block.
Arne Vajhøj
2020-11-21 01:39:28 UTC
Reply
Permalink
Post by seasoned_geek
The XML prologue is usually not the first block as it is preceded
with various headers.
You have zero idea what was asked by a client and less than zero idea
what is happening in their Internet transactions. They have a SALT.
That is why I put it in upper case. For a goodly number of their
transactions the XML protocol is the first block.
They can use a custom protocol on top of direct SSL.

But the common usage of SSL is HTTPS and with HTTPS
there are a bunch of HTTP headers at the beginning.

Arne
Arne Vajhøj
2020-11-12 00:16:46 UTC
Reply
Permalink
Post by seasoned_geek
Post by Arne Vajhøj
Post by seasoned_geek
Post by Grant Taylor
Judicious firewalling can offer the same level of protection for
the other systems without the complexity of the other protocol(s).
Not even in a fantasy world can a firewall offer the above level of
security and up-time.
What you described above is a firewall.
One NIC on the outside and one NIC on the inside and no way
to the inside systems except through the 2 NIC box - that is
what is called a firewall.
And since there is no access to the inside network,
then the security benefits of another protocol
on the inside network are not that big.
The vast majority of firewalls aren't hardware at all.
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/sec-using_firewalls
https://openport.net/centos-firewall/
https://www.ubuntu18.com/how-to-enable-ubuntu-firewall-in-ubuntu-20-04/
https://www.windowscentral.com/how-open-port-windows-firewall
True.

Those port blocking software like Windows Defender and Linux iptables
(firewalld and ufw are just something nice on top of iptables)
for some reason was named "software firewalls".

And they may be valuable for desktop PC's.

But I hope that server installation does not rely on those.
Having a system protect itself is not as good as having
another system in front.

They need real network separation. Either a hardware firewall
or a virtual firewall, which even though it is software is not
the same as a "software firewall".
Post by seasoned_geek
Even when one has a firewall in a router, PASSTHROUGH PORTS ARE ENABLED for many things.
Hopefully all ports inbound are closed.
Post by seasoned_geek
A firewall is not taking a free-form XML/whatever "open" Internet
message and chopping it down into a fixed field length fixed record
width message for a queue. This means the people stuffing a billing
characters or some other nonsense into that free format message to
trigger an overrun so they can perform an SQL injection or some other
hack physically can't happen. When someone tries to move a billion
characters into a COBOL PIC X(25) field, what happens? The first 25
characters make it and the rest land in the bit bucket.
Protocol conversion is sometimes used.

But then it will typical be:

--firewall--protocol conversion--firewall--backend system

For the same reason as firewall in front of system is better
than "software firewall" on system. Better isolation - less risk
in case something bad happens in the protocol conversion.

And stuffing into fixed length format is totally insufficient
as data validation.
Post by seasoned_geek
You are completely incorrect about Security by Obscurity as well. ALL
ENCRYPTION is security by obscurity. Period.
Not by the definition of security by obscurity commonly used.

Arne
seasoned_geek
2020-11-20 12:35:20 UTC
Reply
Permalink
Post by Arne Vajhøj
But I hope that server installation does not rely on those.
Having a system protect itself is not as good as having
another system in front.
A very large number are, that is why there is so much documentation on how to set it up.
Post by Arne Vajhøj
Post by seasoned_geek
Even when one has a firewall in a router, PASSTHROUGH PORTS ARE ENABLED for many things.
Hopefully all ports inbound are closed.
They generally cannot be.
Post by Arne Vajhøj
Post by seasoned_geek
A firewall is not taking a free-form XML/whatever "open" Internet
message and chopping it down into a fixed field length fixed record
width message for a queue. This means the people stuffing a billing
characters or some other nonsense into that free format message to
trigger an overrun so they can perform an SQL injection or some other
hack physically can't happen. When someone tries to move a billion
characters into a COBOL PIC X(25) field, what happens? The first 25
characters make it and the rest land in the bit bucket.
Protocol conversion is sometimes used.
--firewall--protocol conversion--firewall--backend system
For the same reason as firewall in front of system is better
than "software firewall" on system. Better isolation - less risk
in case something bad happens in the protocol conversion.
And stuffing into fixed length format is totally insufficient
as data validation.
Nobody said it was data validation. It is protection. By itself it stops 100% of the data overrun exploits and an extremely high number of SLQ injection techniques. I won't say all because I cannot be certain there isn't one that can do it within the 35 characters allowed for a street address line.
Post by Arne Vajhøj
Post by seasoned_geek
You are completely incorrect about Security by Obscurity as well. ALL
ENCRYPTION is security by obscurity. Period.
Not by the definition of security by obscurity commonly used.
Not by _your_ definition.

Encryption is simply bragging about the size of the forest one is about to hide a tree in, falsely believing the tree cannot be found.

AGILE is not software engineering. It is so far from software engineering it cannot even mail a letter to software engineering, yet _your_ definition of software engineering allows for it.

Chanting the mantra of "no known vulnerabilities" does not make something secure.
Arne Vajhøj
2020-11-21 00:52:00 UTC
Reply
Permalink
Post by seasoned_geek
Post by Arne Vajhøj
Post by seasoned_geek
Even when one has a firewall in a router, PASSTHROUGH PORTS ARE
ENABLED for many things.
Hopefully all ports inbound are closed.
They generally cannot be.
Of course they can.

It is standard for such products to come with all inbound ports closed.
Post by seasoned_geek
Post by Arne Vajhøj
Post by seasoned_geek
A firewall is not taking a free-form XML/whatever "open"
Internet message and chopping it down into a fixed field length
fixed record width message for a queue. This means the people
stuffing a billing characters or some other nonsense into that
free format message to trigger an overrun so they can perform an
SQL injection or some other hack physically can't happen. When
someone tries to move a billion characters into a COBOL PIC X(25)
field, what happens? The first 25 characters make it and the rest
land in the bit bucket.
Protocol conversion is sometimes used.
--firewall--protocol conversion--firewall--backend system
For the same reason as firewall in front of system is better than
"software firewall" on system. Better isolation - less risk in case
something bad happens in the protocol conversion.
And stuffing into fixed length format is totally insufficient as
data validation.
Nobody said it was data validation. It is protection. By itself it
stops 100% of the data overrun exploits
Actually it enables data overrun exploits if the code is bad.

Data overruns are a fixed length format problem only.
Post by seasoned_geek
and an extremely high number
of SLQ injection techniques. I won't say all because I cannot be
certain there isn't one that can do it within the 35 characters
allowed for a street address line.
Have you ever read anything about SQL injection?

35 characters is more than sufficient for many cases of SQL injection.
Post by seasoned_geek
Post by Arne Vajhøj
Post by seasoned_geek
You are completely incorrect about Security by Obscurity as well.
ALL ENCRYPTION is security by obscurity. Period.
Not by the definition of security by obscurity commonly used.
Not by _your_ definition.
Given that the wikipedia article use the same definition and
that other people here also use that definition, then it is
obviously not my definition.

Arne
seasoned_geek
2020-11-21 01:18:12 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by seasoned_geek
Post by Arne Vajhøj
Post by seasoned_geek
Even when one has a firewall in a router, PASSTHROUGH PORTS ARE
ENABLED for many things.
Hopefully all ports inbound are closed.
They generally cannot be.
Of course they can.
No. They can't if things are to get through.
Post by Arne Vajhøj
Post by seasoned_geek
Nobody said it was data validation. It is protection. By itself it
stops 100% of the data overrun exploits
Actually it enables data overrun exploits if the code is bad.
Data overruns are a fixed length format problem only.
MY GOD, QUIT TYPING!!!

You have never worked with Websphere or any of the other message translation sacrificial machine on the Internet tools. I have. That's a physical impossibility. It's a physical mapping. X number of bytes from this tag in this spot. It's the exact same engine for everything.
Post by Arne Vajhøj
Have you ever read anything about SQL injection?
35 characters is more than sufficient for many cases of SQL injection.
Not when one has competent developers and has a tool like Websphere (or one of its competitors) creating fixed length messages that are ultimately being processed by COBOL via SQLmod from within an ACMS server, no, 35 is not enough because the code set doesn't allow anything through.

Now, if you are a Java programmer who knows nothing about large scale corporate systems then one byte is probably enough to knock your code over.
Post by Arne Vajhøj
Given that the wikipedia article use the same definition and
that other people here also use that definition, then it is
obviously not my definition.
Absolutely anyone can edit Wikipedia. Did you quick run out and put your own definition in there?
Scott Dorsey
2020-10-19 20:33:27 UTC
Reply
Permalink
Post by Grant Taylor
Post by seasoned_geek
There is a growing need for an OS without any TCP/IP stack. *nix did
it wrong. There is absolutely no way of securing any system using
*nix based TCP/IP when it is connected to the Internet.
I can't agree with that.
Sure, putting a system on the Internet exposes it to more harm than
sitting in a room by itself with no external connectivity. But then
again, powering the system on exposes it to more harm than completely
disconnecting it from power.
A person who believes as seasoned_geek does should run an operating system
in which the tcp/ip stack is not an integral part of the kernel. Like,
for example, 4.1BSD.. which... just so happens to run on the vax!
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
seasoned_geek
2020-10-23 20:32:09 UTC
Reply
Permalink
Post by Scott Dorsey
Post by Grant Taylor
Post by seasoned_geek
There is a growing need for an OS without any TCP/IP stack. *nix did
it wrong. There is absolutely no way of securing any system using
*nix based TCP/IP when it is connected to the Internet.
I can't agree with that.
Sure, putting a system on the Internet exposes it to more harm than
sitting in a room by itself with no external connectivity. But then
again, powering the system on exposes it to more harm than completely
disconnecting it from power.
A person who believes as seasoned_geek does should run an operating system
in which the tcp/ip stack is not an integral part of the kernel. Like,
for example, 4.1BSD.. which... just so happens to run on the vax!
--scott
Which would have the 25+ year old Bash shell super vulnerability. They don't need to have the IP stack running as part of the kernel as long as they can crack IP enough to get a Bash sell under even a GUEST account. With that vulnerability they will be God on the machine.

There simply is no way to secure any OS that is running *nix based TCP/IP. None.
Scott Dorsey
2020-10-23 22:52:19 UTC
Reply
Permalink
Post by Grant Taylor
There is a growing need for an OS without any TCP/IP stack. *nix did=
=20
Post by Grant Taylor
it wrong. There is absolutely no way of securing any system using=20
*nix based TCP/IP when it is connected to the Internet.=20
I can't agree with that.
Sure, putting a system on the Internet exposes it to more harm than=20
sitting in a room by itself with no external connectivity. But then=20
again, powering the system on exposes it to more harm than completely=20
disconnecting it from power.
=20
A person who believes as seasoned_geek does should run an operating syste=
m
in which the tcp/ip stack is not an integral part of the kernel. Like,
for example, 4.1BSD.. which... just so happens to run on the vax!
Which would have the 25+ year old Bash shell super vulnerability. They don'=
t need to have the IP stack running as part of the kernel as long as they c=
an crack IP enough to get a Bash sell under even a GUEST account. With that=
vulnerability they will be God on the machine.
Bash? On 4.1BSD? You're more than a decade too early.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
Simon Clubley
2020-10-24 18:03:55 UTC
Reply
Permalink
Post by seasoned_geek
Post by Scott Dorsey
A person who believes as seasoned_geek does should run an operating system
in which the tcp/ip stack is not an integral part of the kernel. Like,
for example, 4.1BSD.. which... just so happens to run on the vax!
--scott
Which would have the 25+ year old Bash shell super vulnerability. They don't
need to have the IP stack running as part of the kernel as long as they can
crack IP enough to get a Bash sell under even a GUEST account. With that
vulnerability they will be God on the machine.
Huh? What makes you think Bash would have been the shell on that version
of Unix ?

25 years is a long time, but in this case Bash needed to be used from
within a privileged program that executed commands via Bash in order
for the exploit to be usable.

Did you hear about the operating system that had a similar vulnerability
which wasn't found for 33 years and which could be exploited directly
from the shell shipped with the operating system provided you had
direct access to the shell's command line ?

You could exploit it on the first two architectures this operating system
was supplied for and it's an open question whether someone familiar with
the third architecture this operating system runs on could also change
the exploit to do something bad on that third architecture.
Post by seasoned_geek
There simply is no way to secure any OS that is running *nix based TCP/IP. None.
In the case of the 33-year-old vulnerability, you didn't need a network
stack to exploit it. Direct access to the operating system supplied
shell was sufficient.

BTW, that operating system was VMS, and the shell was DCL.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Phillip Helbig (undress to reply)
2020-10-24 21:51:10 UTC
Reply
Permalink
Post by Simon Clubley
BTW, that operating system was VMS, and the shell was DCL.
Was it ever used in a malicious exploit?
Bill Gunshannon
2020-10-24 22:24:58 UTC
Reply
Permalink
Post by Phillip Helbig (undress to reply)
Post by Simon Clubley
BTW, that operating system was VMS, and the shell was DCL.
Was it ever used in a malicious exploit?
The exploit you never know about is much more of a problem than the ones
you do know about.

bill
Simon Clubley
2020-10-25 17:18:01 UTC
Reply
Permalink
Post by Bill Gunshannon
Post by Phillip Helbig (undress to reply)
Post by Simon Clubley
BTW, that operating system was VMS, and the shell was DCL.
Was it ever used in a malicious exploit?
Seriously, Phillip ?

If someone did find and use it, they are not likely to talk about it... :-)
Post by Bill Gunshannon
The exploit you never know about is much more of a problem than the ones
you do know about.
Exactly. In the 33 years this was around, you can't assume I was
the first one to find this.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
abrsvc
2020-10-25 17:57:04 UTC
Reply
Permalink
Post by Simon Clubley
Post by Bill Gunshannon
Post by Phillip Helbig (undress to reply)
Post by Simon Clubley
BTW, that operating system was VMS, and the shell was DCL.
Was it ever used in a malicious exploit?
Seriously, Phillip ?
If someone did find and use it, they are not likely to talk about it... :-)
Post by Bill Gunshannon
The exploit you never know about is much more of a problem than the ones
you do know about.
Exactly. In the 33 years this was around, you can't assume I was
the first one to find this.
Simon.
--
Walking destinations on a map are further away than they appear.
Don't be too sure. I am aware of a microcode bug for the RET instruction on the 11/780 that was discovered about 25 years after its introduction. I know that it wasn't fixed because it was never found prior to that. So, yes things can be wrong for an extended period of time without discovery.
Simon Clubley
2020-10-26 00:29:30 UTC
Reply
Permalink
Post by abrsvc
Don't be too sure. I am aware of a microcode bug for the RET instruction on the 11/780 that was discovered about 25 years after its introduction. I know that it wasn't fixed because it was never found prior to that. So, yes things can be wrong for an extended period of time without discovery.
Let me guess: it wasn't properly checking the current mode versus
the stored mode on the stack ?

I've never heard of this bug so that's just a guess based on the
fact you brought it up in a security discussion.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
abrsvc
2020-10-26 11:24:04 UTC
Reply
Permalink
Post by Simon Clubley
Post by abrsvc
Don't be too sure. I am aware of a microcode bug for the RET instruction on the 11/780 that was discovered about 25 years after its introduction. I know that it wasn't fixed because it was never found prior to that. So, yes things can be wrong for an extended period of time without discovery.
Let me guess: it wasn't properly checking the current mode versus
the stored mode on the stack ?
I've never heard of this bug so that's just a guess based on the
fact you brought it up in a security discussion.
Simon.
--
Walking destinations on a map are further away than they appear.
I honestly don't recall the specifics as it was quite a while ago, but I do know that it was never fixed as the "bug" had been in existence for over 20 years without any reports other that one problem that ended up being traced to it. I was working at DEC at the time, so it is possible that the report was in an internal doc, but I don't recall. Nothing to do with security BTW. Just making the point that "bugs" can exist for a long time without discovery.
gah4
2020-11-08 06:10:48 UTC
Reply
Permalink
On Monday, October 26, 2020 at 4:24:06 AM UTC-7, abrsvc wrote:

(snip)
I honestly don't recall the specifics as it was quite a while ago, but I do know that it was never fixed as the "bug" had been in existence for over 20 years without any reports other that one problem that ended up being traced to it. I was working at DEC at the time, so it is possible that the report was in an internal doc, but I don't recall. Nothing to do with security BTW. Just making the point that "bugs" can exist for a long time without discovery.
This is reminding me of a story about a TOPS-10 bug that I heard 40 years ago.

It seems that the QUEUE command has an option to run a program when finished.
(This is used so a program can run it, and then get control back.)

The system also lets you run QUEUE when not logged in, so you can check
the status of jobs.

It seems it took some time to figure out that both features could be used together,
but finally someone sent in a bug report ... and checked the PUBLISH option on the form.
V***@SendSpamHere.ORG
2020-10-25 13:43:08 UTC
Reply
Permalink
Post by Simon Clubley
Post by seasoned_geek
Post by Scott Dorsey
A person who believes as seasoned_geek does should run an operating system
in which the tcp/ip stack is not an integral part of the kernel. Like,
for example, 4.1BSD.. which... just so happens to run on the vax!
--scott
Which would have the 25+ year old Bash shell super vulnerability. They don't
need to have the IP stack running as part of the kernel as long as they can
crack IP enough to get a Bash sell under even a GUEST account. With that
vulnerability they will be God on the machine.
Huh? What makes you think Bash would have been the shell on that version
of Unix ?
25 years is a long time, but in this case Bash needed to be used from
within a privileged program that executed commands via Bash in order
for the exploit to be usable.
Did you hear about the operating system that had a similar vulnerability
which wasn't found for 33 years and which could be exploited directly
from the shell shipped with the operating system provided you had
direct access to the shell's command line ?
You could exploit it on the first two architectures this operating system
was supplied for and it's an open question whether someone familiar with
the third architecture this operating system runs on could also change
the exploit to do something bad on that third architecture.
Post by seasoned_geek
There simply is no way to secure any OS that is running *nix based TCP/IP. None.
In the case of the 33-year-old vulnerability, you didn't need a network
stack to exploit it. Direct access to the operating system supplied
shell was sufficient.
BTW, that operating system was VMS, and the shell was DCL.
https://images.app.goo.gl/A9QJ315U5iJ2j1d29
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.
Alexander Schreiber
2020-11-02 10:02:32 UTC
Reply
Permalink
Post by seasoned_geek
Post by Bill Gunshannon
....now that VMS is going to be come persona non grata.
It has been decades, but, I used to work with an OS written by
Tannenbaum called Amoeba. A couple of grad students did a thesis
project on it using Sparcstations and it was really impressive to
watch it run. I had forgotten that it also ran on the VAX. Might
be fun to put it on my stack of VAXStations and see what it might
do.
By the way, for those who think that VMS is the only real share
everything clustering system, Amoeba was really good about sharing.
Too bad, like so many academic endeavors, people got bored with it
and it withered on the vine. Like Plan9 and Inferno.
bill
There is a growing need for an OS without any TCP/IP stack. *nix did it
wrong.
Just for the record:
- Unix was around before TCP/IP became a thing
- as far back as the 90s there was at _least_ one Unix on the commercial
market where the TCP/IP stack was an optional added product (Coherent)
- Unix absolutely does not _require_ a TCP/IP stack, the systems usually
just are more useful _with_ one
Post by seasoned_geek
There is absolutely no way of securing any system using *nix based
TCP/IP when it is connected to the Internet.
That is, to say it politely, utter nonsense. Yes, securing a network service
is a non-trivial exercise, because it requires more than just grabbing
random code from the Internet, nailing it together and calling it done
(e.g. the NodeJs and friends approach). You need to actually understand
what your are trying to achieve, what you are doing, pay attention to
security starting at the design stage and be competent. If you can't
measure up to this, you have no business building network services.

That is entirely doable and being demonstrated on a daily basis.
Post by seasoned_geek
Lots of places dusting off
old proprietary protocols for internal networks, putting one or two
sacrificial machines out on the Internet and only installing/allowing
the proprietary protocol between them and the internal network.
Well, there are clueless idiots in charge everywhere:
- Shannons Maxim applies ("The enemy knows the system.")
- proprietary protocols means fewer people have looked at the design
and implementation, it's less widely used, less stress tested and
most likely has bugs that more commonly used services fixed ages
ago

Those places might now be safe from the stereotypical clueless teenager
in his Moms basement that only knows how to click the "Haxx0r it!" button,
but they do make inviting targets for the kind of people who enjoy solving
weird puzzles, thus attracting a more competent crowd of attackers.

Kind regards,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
seasoned_geek
2020-11-11 15:19:30 UTC
Reply
Permalink
Post by Alexander Schreiber
Post by seasoned_geek
There is absolutely no way of securing any system using *nix based
TCP/IP when it is connected to the Internet.
That is, to say it politely, utter nonsense. Yes, securing a network service
is a non-trivial exercise, because it requires more than just grabbing
random code from the Internet, nailing it together and calling it done
(e.g. the NodeJs and friends approach). You need to actually understand
what your are trying to achieve, what you are doing, pay attention to
security starting at the design stage and be competent. If you can't
measure up to this, you have no business building network services.
That is entirely doable and being demonstrated on a daily basis.
You mean they are breached on a daily basis. So often in fact they hardly make the news unless they set a new identity theft record.
Post by Alexander Schreiber
Post by seasoned_geek
Lots of places dusting off
old proprietary protocols for internal networks, putting one or two
sacrificial machines out on the Internet and only installing/allowing
the proprietary protocol between them and the internal network.
- Shannons Maxim applies ("The enemy knows the system.")
- proprietary protocols means fewer people have looked at the design
and implementation, it's less widely used, less stress tested and
most likely has bugs that more commonly used services fixed ages
ago
Like the Bash security breach exploited for ~25 years before being outted in public?
Simon Clubley
2020-11-11 18:43:44 UTC
Reply
Permalink
Post by seasoned_geek
Like the Bash security breach exploited for ~25 years before being outted in public?
I noticed you never replied to my response to this.

Is that because I pointed out a very inconvenient truth that you
would prefer to ignore ?

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
seasoned_geek
2020-11-20 12:27:00 UTC
Reply
Permalink
Post by Simon Clubley
Post by seasoned_geek
Like the Bash security breach exploited for ~25 years before being outted in public?
I noticed you never replied to my response to this.
Is that because I pointed out a very inconvenient truth that you
would prefer to ignore ?
No. I didn't see a question requiring a response. The Bash comment was pointing out how a terminal shell thought to be "secure" with so many chanting the mantra "no known security vulnerabilities" had one that was exploited for over two decades.

Korn Shell has had numerous long term security issues as well. Here's one first recorded in 1998.
https://www.cvedetails.com/cve/CVE-1999-1114/
God only knows how long it was actually in the wild.

There was a misunderstanding with respect to the _point_ of the comment.

I haven't been coming here often.

Not that it will change your life in any way, but this is the year of COVID-19 lockdowns at nursing homes followed by navigating Hospice care under COVID-19 followed by loss of my father (during harvest season no less) and currently dealing with all of the probate sh*t, headstone selection, etc.

I know this group likes going down distant rabbit holes but honestly I never found them enjoyable and certainly don't have the left over bandwidth for them right now.

Honestly, I don't read every message in most threads because I don't want to snap a knee in an unseen rabbit hole.
Simon Clubley
2020-11-20 13:37:22 UTC
Reply
Permalink
Post by seasoned_geek
Post by Simon Clubley
Post by seasoned_geek
Like the Bash security breach exploited for ~25 years before being outted in public?
I noticed you never replied to my response to this.
Is that because I pointed out a very inconvenient truth that you
would prefer to ignore ?
No. I didn't see a question requiring a response. The Bash comment was pointing out how a terminal shell thought to be "secure" with so many chanting the mantra "no known security vulnerabilities" had one that was exploited for over two decades.
And how is that any different from DCL where people said the same thing
about VMS and DCL until I came along and found that DCL had a vulnerability
which allowed non-privileged people to compromise VAX/VMS and later Alpha
VMS on VMS versions spanning a 33 year period ?
Post by seasoned_geek
Korn Shell has had numerous long term security issues as well. Here's one first recorded in 1998.
https://www.cvedetails.com/cve/CVE-1999-1114/
That sounds very similar to DCL (in concept and vulnerability scope at least).
Post by seasoned_geek
God only knows how long it was actually in the wild.
In the case of DCL, it was in the wild for 33 years. I doubt the Korn
shell existed in 1966 (1999 - 33). :-)

What people like you and Phillip need to understand is that vulnerabilities
exist everywhere and the less popular the OS, the more likely they are to
be silently exploited until a security researcher finally invests the time
to probe the OS.

VMS has many good features but it doesn't mean that you can ignore some
uncomfortable truths about security on VMS and claim there isn't a
problem on VMS simply because no-one has invested the time to find
those vulnerabilities yet.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Stephen Hoffman
2020-11-20 15:52:59 UTC
Reply
Permalink
Post by Simon Clubley
What people like you and Phillip need to understand is that
vulnerabilities exist everywhere and the less popular the OS, the more
likely they are to be silently exploited until a security researcher
finally invests the time to probe the OS.
Security through obscurity. The obscurity of the whole platform, in
this case. And I too expect that detailed investigations will find
additional exploits, though the still-prevalent usage of unencrypted
storage protocols and of DECnet and telnet and ftp can all make that
extra investment unnecessary for many targets.
Post by Simon Clubley
VMS has many good features but it doesn't mean that you can ignore some
uncomfortable truths about security on VMS and claim there isn't a
problem on VMS simply because no-one has invested the time to find
those vulnerabilities yet.
Or somebody has found exploits, and has been quietly sitting on those
exploits. That DEF CON SMG exploit a while back sure looked like
somebody leaked an exploit from a cache of vulnerabilities somewhere.

Exploit usage and exploit value differs for rare systems, and for those
systems that are ubiquitous. An OpenVMS botnet makes little sense, as
there are so few around. There are presently just shy of 1300 OpenVMS
systems connected and accessible via the internet, with others not
directly accessible and maybe a few more accessible but sufficiently
masking their own identity. For a more ubiquitous system, use as a
botnet or other mass exploitation becomes more interesting. Usage which
then exposes the exploits.

General:

AES symmetric encryption brute force is beyond current known
capabilities. Brute-force timescales where we could more quickly visit
other stars with our current tech. This absent either side channel
access to the software using the keys (faster, though
processor-integrated AES support reduces the vulnerability to side
channel access), or an error in a specific encryption implementation,
or with a whole lot of known plaintext (still beyond slow). This being
security by design, rather than obscurity. And if somebody does have a
trapdoor in AES, they're not going to want that known.

TLS asymmetric encryption design errors and attacks, and TLS
implementation errors, have been more prevalent, with TLS itself
receiving updates. TLSv1.3 is current, earlier protocol implementations
are known to have weaknesses. I would not recommend using anything
prior to TLSv1.2. As vulnerabilities and exploits are identified,
remediations are implemented.

OpenVMS has some support for AES and for TLS, but does not have a
cryptographic framework that can isolate apps from and abstract the
lower-level changes and updates, for those apps that do use AES or TLS.
I'm here ignoring the long-abandoned CDSA, and referring to an
abstraction above the current ENCRYPT and TLS APIs. And among other
gaps, OpenVMS lacks a password store, a certificate store, integrated
multi-factor authentication, cryptographic secure storage and
encryption acceleration hardware, and full-device encryption support.
Intel SGX secure enclave usage might be feasible once the OpenVMS x86
port is available, but the whole SGX approach has been problematic for
a while.

OpenVMS VAX security (tying back to the original question) is more
problematic, as OpenVMS VAX predates the integration of AES support in
the V8 range, and the TLS and SSH support for OpenVMS VAX is
third-party where available. And the end of the HPE hobbyist licenses
will split off those that want VAX from those that want a way to run
OpenVMS on low-end hardware.
--
Pure Personal Opinion | HoffmanLabs LLC
seasoned_geek
2020-11-20 16:14:21 UTC
Reply
Permalink
Post by Simon Clubley
Post by seasoned_geek
Post by Simon Clubley
Post by seasoned_geek
Like the Bash security breach exploited for ~25 years before being outted in public?
I noticed you never replied to my response to this.
Is that because I pointed out a very inconvenient truth that you
would prefer to ignore ?
No. I didn't see a question requiring a response. The Bash comment was pointing out how a terminal shell thought to be "secure" with so many chanting the mantra "no known security vulnerabilities" had one that was exploited for over two decades.
And how is that any different from DCL where people said the same thing
about VMS and DCL until I came along and found that DCL had a vulnerability
which allowed non-privileged people to compromise VAX/VMS and later Alpha
VMS on VMS versions spanning a 33 year period ?
I didn't say it was and yes, I've seen you break your arm patting yourself on the back for quite some time now. <Grin>
Post by Simon Clubley
Post by seasoned_geek
Korn Shell has had numerous long term security issues as well. Here's one first recorded in 1998.
https://www.cvedetails.com/cve/CVE-1999-1114/
That sounds very similar to DCL (in concept and vulnerability scope at least).
Post by seasoned_geek
God only knows how long it was actually in the wild.
In the case of DCL, it was in the wild for 33 years. I doubt the Korn
shell existed in 1966 (1999 - 33). :-)
My needing to know that was not the point of the statement.
Post by Simon Clubley
What people like you and Phillip need to understand is that vulnerabilities
exist everywhere and the less popular the OS, the more likely they are to
be silently exploited until a security researcher finally invests the time
to probe the OS.
To some extent this is true.

To a much broader extent though, competent system managers never connected VMS directly to the Internet. There was always something like Websphere or some other sacrificial system out there, converting insecure highly risky Internet traffic into fixed field with fixed length messages and placing them on message queues. It was not a firewall, it was a sacrificial computer on a completely different network with a different protocol. Believe it or not, OS/2 is back from the grave

https://www.logikalsolutions.com/wordpress/information-technology/os2-back-from-the-grave/

because there are too many banks/ATMs/other financial institutions still using it and the protocols kids today won't bother to read even if the documentation is free online.

Phillip is also correct that Ease plays a big roll in choosing financial targets. There is no up-side for a CC theft ring in breaching a steel mill and that would be assuming a steel mill put its VMS system on the Internet. As far as I can tell, most of the Credit Unions that ran VMS back in the day didn't connect those systems to the Internet either.

Wow!
I forgot just how long this has been popping up on my radar.

https://www.logikalsolutions.com/wordpress/information-technology/so-secure-you-are-insecure/

https://www.logikalsolutions.com/wordpress/information-technology/a-tcp-up-software-appliance/

https://www.logikalsolutions.com/wordpress/information-technology/you-are-the-security-breach/

Some early musings before I came to the concept of each SALT value having its own table. It was only about two hours of effort though. I knew I wasn't going to have time to work on it and wanted it some place I could easily find.
https://www.logikalsolutions.com/wordpress/information-technology/breaching-tls-ssl/

There is also an essay in my new book: https://www.barnesandnoble.com/w/the-minimum-you-need-to-know-about-the-phallus-of-agile-roland-hughes/1137960971?ean=9781939732095

"Security Via Obsolescence"

Just how many places are left that can read 8-inch floppies? 6250 tapes? Probably more for the tapes than the 8-inch floppies. Bulletin board systems, once all of the rage, long since faded, are now the secure way to communicate predominately because next to nobody has a modem and a cheap laptop has more horsepower than we ever had to run them back in the day.
Simon Clubley
2020-11-20 18:49:19 UTC
Reply
Permalink
Post by seasoned_geek
Post by Simon Clubley
And how is that any different from DCL where people said the same thing
about VMS and DCL until I came along and found that DCL had a vulnerability
which allowed non-privileged people to compromise VAX/VMS and later Alpha
VMS on VMS versions spanning a 33 year period ?
I didn't say it was and yes, I've seen you break your arm patting yourself on the back for quite some time now. <Grin>
Good. :-) That means the message is continuing to get through to at least
some people and that perhaps there will not be such a major state of denial
when the next person comes along with another VMS vulnerability.

One of the unique features of that vulnerability was the sheer amount
of denial that was going on when people found out about it. If you are
not even willing to consider that such a vulnerability might exist, then
you are unlikely to be willing to consider how to protect your systems
from those and other similar types of vulnerabilities.

Reminding people about it every so often helps remind them that other
similar vulnerabilities might also exist.
Post by seasoned_geek
"Security Via Obsolescence"
Just how many places are left that can read 8-inch floppies? 6250 tapes?
Probably more for the tapes than the 8-inch floppies.
What about 800bpi tapes, paper tapes, Exabyte cartridges, WORM cartridges,
MFM hard drives, and DECtape ? :-)

As an aside, I wonder how many people today even know that EBCDIC exists
when it comes to talking about alternate ways to store data ?

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Bill Gunshannon
2020-11-20 19:43:10 UTC
Reply
Permalink
Post by Simon Clubley
Post by seasoned_geek
Post by Simon Clubley
And how is that any different from DCL where people said the same thing
about VMS and DCL until I came along and found that DCL had a vulnerability
which allowed non-privileged people to compromise VAX/VMS and later Alpha
VMS on VMS versions spanning a 33 year period ?
I didn't say it was and yes, I've seen you break your arm patting yourself on the back for quite some time now. <Grin>
Good. :-) That means the message is continuing to get through to at least
some people and that perhaps there will not be such a major state of denial
when the next person comes along with another VMS vulnerability.
One of the unique features of that vulnerability was the sheer amount
of denial that was going on when people found out about it. If you are
not even willing to consider that such a vulnerability might exist, then
you are unlikely to be willing to consider how to protect your systems
from those and other similar types of vulnerabilities.
Reminding people about it every so often helps remind them that other
similar vulnerabilities might also exist.
Post by seasoned_geek
"Security Via Obsolescence"
Just how many places are left that can read 8-inch floppies? 6250 tapes?
Probably more for the tapes than the 8-inch floppies.
I can do both of them.
Post by Simon Clubley
What about 800bpi tapes, paper tapes, Exabyte cartridges, WORM cartridges,
MFM hard drives, and DECtape ? :-)
As an aside, I wonder how many people today even know that EBCDIC exists
when it comes to talking about alternate ways to store data ?
Well, if your going to give the nod to EBCDIC, don't ignore Fieldata.

bill
Arne Vajhøj
2020-11-20 22:32:57 UTC
Reply
Permalink
Post by Simon Clubley
As an aside, I wonder how many people today even know that EBCDIC exists
when it comes to talking about alternate ways to store data ?
Know EBCDIC specifically? Probably only a small bunch of guys over 50.

Know that data can be stored differently and be able to
get a list of what is possible in their environment? Millions!

import java.nio.charset.Charset;
import java.util.Map.Entry;

public class CharsetList {
public static void main(String[] args) {
for(Entry<String,Charset> e :
Charset.availableCharsets().entrySet()) {
System.out.println(e.getKey() + " = " +
e.getValue().aliases());
}
}
}

list 156 encodings including 10 flavors of EBCDIC
with Java 5 on VMS.

(and 170 including 21 flavors of EBCDIC with Java 8
on Windows)

using System;
using System.Text;

namespace E
{
public class Program
{
public static void Main(string[] args)
{
foreach(EncodingInfo ei in Encoding.GetEncodings())
{
Console.WriteLine(ei.Name + " = " + ei.DisplayName);
}
Console.ReadKey();
}
}
}

list 140 encodings including 31 flavors of EBCDIC with
.NET 4 on Windows.

Arne
Arne Vajhøj
2020-11-21 00:43:26 UTC
Reply
Permalink
Post by seasoned_geek
Believe it or not, OS/2 is back from the grave
https://www.logikalsolutions.com/wordpress/information-technology/os2-back-from-the-grave/
because there are too many banks/ATMs/other financial institutions
still using it and the protocols kids today won't bother to read even
if the documentation is free online.
OS/2 is not coming back as mainstream OS.

ArcaOS is a niche OS for those stuck on 20 year old technology.

https://www.arcanoae.com/arcaos/ reveals what it is all about:

<quote>
ArcaOS runs…

…OS/2 applications (32-bit and 16-bit)
…16-bit Windows applications
…DOS applications
</quote>

it also list some newer stuff, but listing these 3 app types as the
first app types pretty clearly indicate what the market is.

Arne
Phillip Helbig (undress to reply)
2020-11-20 14:41:14 UTC
Reply
Permalink
Post by Simon Clubley
What people like you and Phillip need to understand is that vulnerabilities
exist everywhere
Yes, very probably.
Post by Simon Clubley
and the less popular the OS, the more likely they are to
be silently exploited until a security researcher finally invests the time
to probe the OS.
Yes, but on the other hand the fact that it is less popular means that
it is no as interesting as a target. You are interested in the product
E*I, where E is "easy to exploit because there are fewer people
concerned about exploits" (because there are fewer people) and I is
"interesting for the person who wants to exploit it" (probably because
there are many such systems). You are arguing that E is higher for VMS,
which might be true, but I is certainly much lower, so it is unclear
whether the product E*I is higher or lower for VMS (my guess is that it
is lower).
Stephen Hoffman
2020-11-20 16:07:58 UTC
Reply
Permalink
Post by Phillip Helbig (undress to reply)
Yes, but on the other hand the fact that it is less popular means that
it is no as interesting as a target.
Not interesting for botnets, sure. But OpenVMS servers are absolutely
targets. Some are big ones.

Various OpenVMS systems have a whole lot of money flowing through them,
can and do contain credit card information, and other sensitive data.

These servers include large-scale order and payment processing and
stocking apps, banking and investments servers, stock market services,
and suchlike.

Not only are these OpenVMS servers targets, so too is VSI itself and
individually those people associated with VSI, as too are the various
OpenVMS-related freeware sites.
--
Pure Personal Opinion | HoffmanLabs LLC
Phillip Helbig (undress to reply)
2020-11-20 16:55:11 UTC
Reply
Permalink
Post by Stephen Hoffman
Not interesting for botnets, sure. But OpenVMS servers are absolutely
targets. Some are big ones.
Various OpenVMS systems have a whole lot of money flowing through them,
can and do contain credit card information, and other sensitive data.
These servers include large-scale order and payment processing and
stocking apps, banking and investments servers, stock market services,
and suchlike.
And usually (always?) not connected to the internet. That doesn't mean
that no unauthorized access is possible, but if it is, then there are
probably much bigger problems.
Stephen Hoffman
2020-11-20 17:18:48 UTC
Reply
Permalink
Post by Phillip Helbig (undress to reply)
Post by Stephen Hoffman
Not interesting for botnets, sure. But OpenVMS servers are absolutely
targets. Some are big ones.
Various OpenVMS systems have a whole lot of money flowing through them,
can and do contain credit card information, and other sensitive data.
These servers include large-scale order and payment processing and
stocking apps, banking and investments servers, stock market services,
and suchlike.
And usually (always?) not connected to the internet. That doesn't mean
that no unauthorized access is possible, but if it is, then there are
probably much bigger problems.
At present, just shy of 1300 OpenVMS servers are directly connected to
the internet, among those that are connected and not otherwise masking
their identities.

Some of those OpenVMS servers are running in AWS, too. Those likely
running under emulation.

Above server population info is publicly available.

Other OpenVMS servers are directly connected but not running services
that can be finger-printed, and others are not directly connected.

And multi-step and indirect security attacks on networks are the norm,
and not at all unusual.

Indirect access applies to OpenVMS too, some of which was described in
the previous posting but was omitted from the quoted text. That text,
Post by Phillip Helbig (undress to reply)
Post by Stephen Hoffman
Not only are these OpenVMS servers targets, so too is VSI itself and
individually those people associated with VSI, as too are the various
OpenVMS-related freeware sites.
TL;DR:

Exploit markets and exploit usage differs for mass-deployed clients,
and for isolated and higher-value servers.

For those running OpenVMS in production, patch to current, and
implement monitoring and telemetry for security-relevant events and
activities. Preferably with the collected data remotely logged.

Review the security of your apps and server configurations and your
processes, as well.
--
Pure Personal Opinion | HoffmanLabs LLC
seasoned_geek
2020-11-21 00:59:00 UTC
Reply
Permalink
Post by Stephen Hoffman
At present, just shy of 1300 OpenVMS servers are directly connected to
the internet, among those that are connected and not otherwise masking
their identities.
Some of those OpenVMS servers are running in AWS, too. Those likely
running under emulation.
How many of them are Hobbyist licenses that won't be legal very soon? I've run into lots of OpenVMS Hobbyists that run their own mail server or other thing with an old VaxStation Model 90 or whatever.

What I'm getting at is I will wager the bulk of those aren't business use machines.
Alexander Schreiber
2020-11-11 23:21:44 UTC
Reply
Permalink
Post by seasoned_geek
Post by Alexander Schreiber
Post by seasoned_geek
There is absolutely no way of securing any system using *nix based
TCP/IP when it is connected to the Internet.
That is, to say it politely, utter nonsense. Yes, securing a network service
is a non-trivial exercise, because it requires more than just grabbing
random code from the Internet, nailing it together and calling it done
(e.g. the NodeJs and friends approach). You need to actually understand
what your are trying to achieve, what you are doing, pay attention to
security starting at the design stage and be competent. If you can't
measure up to this, you have no business building network services.
That is entirely doable and being demonstrated on a daily basis.
You mean they are breached on a daily basis. So often in fact they
hardly make the news unless they set a new identity theft record.
Not if the infrastructure is run well and by competent people who are
allowed to do their job. I know a very large, global deployment of various
different types of Unix servers with a very, very boring security history
(as in: nothing happens, even though a lot might be tried). And it _is_
the kind of setup that attracts the usual suspects into attacking by
its very nature.

Of course if the setup is run by .. less than competent people, doing the
usual (not securing system setups before allowing them on the Internet,
not updating systems, keeping default credentials, exposing stuff to
the open Internet that doesn't need to be exposed, ...), well what happens
then is just to be expected.
Post by seasoned_geek
Post by Alexander Schreiber
Post by seasoned_geek
Lots of places dusting off
old proprietary protocols for internal networks, putting one or two
sacrificial machines out on the Internet and only installing/allowing
the proprietary protocol between them and the internal network.
- Shannons Maxim applies ("The enemy knows the system.")
- proprietary protocols means fewer people have looked at the design
and implementation, it's less widely used, less stress tested and
most likely has bugs that more commonly used services fixed ages
ago
Like the Bash security breach exploited for ~25 years before being outted in public?
To exploit bash you need to get code execution on the system in the
first place. And nobody in their right mind wires a shell directly
to an open socket (unless it's part of an exploit). So nobody _looks_
for security holes in stuff that should not be security relevant
in the first place. Until, of course, someone does ...

Kind regards,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
seasoned_geek
2020-11-20 12:38:26 UTC
Reply
Permalink
Post by Alexander Schreiber
Post by seasoned_geek
Like the Bash security breach exploited for ~25 years before being outted in public?
To exploit bash you need to get code execution on the system in the
first place. And nobody in their right mind wires a shell directly
to an open socket (unless it's part of an exploit). So nobody _looks_
for security holes in stuff that should not be security relevant
in the first place. Until, of course, someone does ...
Or you need access to the GUEST account which was left enabled most everywhere because there where "no known vulnerabilities" in the shell and the account itself had no privs.
Loading...