I found it interesting that a CVSS score was included in this post.
Based upon my limited experience with CVSS scores associated with z/OS
vulnerabilities 7.5 is pretty high. For example, a SVC that stores into
a caller specified address while in PSW Key 0 Supervisor state and the
unauthorized requester can control what that address is would be in the
same range. The SVC vulnerability could be used to crash the system,
dynamically elevate security credentials, turn off logging, etc..... The
SVC vulnerability represents a serious compromise of the implemented
z/OS security as well as a violation of any reasonable compliance standard.
The web site (http://nvd.nist.gov/cvss.cfm?calculator&version=2
<http://nvd.nist.gov/cvss.cfm?calculator&version=2>) has a calculator +
a very understandable writeup on how the 7.5 score could be obtained. Of
particular interest to this discussion would be the temporal score
metrics. These metrics rate the availability of exploit, type of fix
available, and level of verification that vulnerability exists (report
confidence). It would appear to me that a valid 7.5 score would require
settings that would imply an exploit existed or could be easily assumed
(for ex - SVC's that code standard linkage are always exploitable and
should not require an exploit). In addition, a 7.5 score would probably
require the exploit to "completely" affect the integrity of the system
(i.e. - similar to the SVC example) as well. Based upon these
assumptions one should be able to reasonably conclude that:
1) You have a vulnerability
2) It is exploitable
3) The exploit if executed on your system will affect the integrity of
that system (and possibly others).
Of course, this assumes that the CVSS score is accurate. But if it is
these are some reasonable assumptions that can be made without the
exploit details.
On 5/6/2011 09:49 AM, Burrell, C. Todd (CDC/OCOO/ITSO) (CTR) wrote:
What they have told me (in their usually secretive way) is that the IP address
for the HMC is listening for RIP announcements. They claim this could be a
security issue since a malicious intruder could send the HMC invalid RIP
announcements and give it bad routes. My response has basically been that the
HMC has been running this way for at least 15 years - and since it is not
available outside of our intranet then what is the big deal, anyway? The only
intruder would have to be an internal user - and I hope folks have better
things to do?
I've pushed this back to them and told them this is not a HIGH security exposure. So
we'll see if this gets them off my back. The ironic thing is that we are working to get
rid of the mainframe, so I see no reason to even try and change anything right now?
Surely there are more important "security" issues than this minor one?
Thanks to everyone for their responses...
C. Todd Burrell
PMP, MCSE 2003:Security
MCTS (640,642,643,647)
Security+, Network+
ITIL V3 Foundations
CSC Lead z/OS Systems Programmer
ITSO
(404) 723-2017 (Cell)
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of
Chris Mason
Sent: Friday, May 06, 2011 10:20 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: RIP issue with HMC - security violation?
Todd
Why do the "security" people assume there is a problem? You didn't make that
clear.
Other contributors have alluded to what really matters but not with maximum
clarity - IMNSHO - or I wouldn't be jumping fearlessly in!
What is implied by what you have told us is a *potential* "security exposure"
is that UDP port has an outstanding socket read-type request pending for it
using an UDP port, 520, which would normally imply that there was a Routing
Information Protocol (RIP) process behind it capable of modifying the routing
table if the socket "sucked in" suitable packets.[1]
-
Note that the use of the word "listen" here is rather confusing - although
everybody does it - a bit like something else I could mention!
Between the two "transport" protocols which sit on top of the IP layer and use
ports to identify application instances, only TCP has a listen() call. This
listen
() call is issued very early in the life of the program, is associated with a
specific port - can also be a specific IP address but I'll keep the discussion
simple - stays "in force" for the duration of the application and can be "seen"
as a "listening" state for the application.
UDP doesn't do that. There's no UDP listen() call. However, when an UDP
application has issued a read-type call specifying a particular port, a packet
can be read and, as swiftly as possible, the application sets up an identical
read-type call - actually leaving a probably very small window where there is
no read-type call in place.
Despite these differences, you will find the discovery of such a read-type call
being in place described as equivalent to the TCP listen state - just to
confuse the unwary!
-
If there is such a read-type call in place in your system for UDP port 520, the
port defined for use by RIP, you should evaluate whether or not you need it.
> From the nature of your post and assuming you are the local specialist in what
the HMC needs to do, I would assume not. In that case you should perform
whatever customisation is available to "kill" this RIP process. Having said
that,
I hope there is such customisation available.
This is not a matter I know anything about. However Roy Hewitt has
suggested disabling "Routing". This would normally imply that your HMC could
act as a "router" which sounds odd but what do I know? It may be that this
includes dispensing with a dynamic routing protocol such as RIP which is, of
course, what you want.
Note there is a concentration of IP-knowledgeable folk on IBMTCP-L:
For IBMTCP-L subscribe / signoff / archive access instructions, send email to
lists...@vm.marist.edu with the message: INFO IBMTCP-L
-
Then I had a rather brilliant idea - sorry for the larded sarcasm! "When all
else
fails, read the manual!"[2]
http://publibfp.dhe.ibm.com/cgi-bin/bookmgr/BOOKS/id1t0c00/2.4.31
seems to be the key. "routed", the traditional name for the daemon which is
responsible for supporting the RIP dynamic routing protocol, seems to be
started by default. Without digging any further into something way, way
outside my "comfort zone", I leave you to dig around to find the precise
switch for "turning RIP off"! Enough for me to know it can be done and this is
the place to start finding out how!
-
Now I trust I will get some credit for actually engaging with the odd
indisputably *technical* contribution!
-
[1] http://en.wikipedia.org/wiki/Routing_Information_Protocol
[2] Something you'll never find Jeremy Clarkson doing!
-
Chris Mason
On Fri, 6 May 2011 00:35:50 +0100, Roy Hewitt<ibm-
m...@frozeneclipse.co.uk> wrote:
Todd,
Have you enabled Routing in the HMC network configuration, there is a check
box for this, just turn
it off. Also check in Network Diagnostic Configuration to show what UDP
ports are listening.. is 520
there?
Cheers
Roy
Todd Burrell wrote:
I got the following info from one of our security folks today about a
potential
security exposure with the HMC. Is it valid that the HMC has a RIP listener
active, or could I potentially turn it off? Any info about this would be
helpful
so I can get the security scan group off my back. Here was the decription
of
the violation:
Synopsis :
Routing tables can be modified.
Description :
The remote RIP listener accepts routes that are not sent by a
neighbor.
This cannot happen in the RIP protocol as defined by RFC2453, and
although the RFC is silent on this point, such routes should probably
be ignored.
A remote attacker might use this flaw to access the local network if
it is not protected by a properly configured firewall, or to hijack
connections.
Solution :
Either disable the RIP listener if it is not used, use RIP-2 in
conjunction with authentication, or use another routing protocol.
Risk Factor :
High / CVSS Base Score : 7.5
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
