sunhux
asked on
Can an external source call gethost (Ghost) function & any port that gethost apps usually listen on?
A governance authority posed a question:
"are external sources able to make calls to GetHost services/functions to Linux servers in our infra ie passing
thru firewall/IPS" ?
Does the question above make sense or it was mixed up with the case below:
http://security.stackexchange.com/questions/80498/can-an-executable-be-scanned-for-calls-to-the-vulnerable-glibc-ghost-functions
If it makes sense, does it go thru Tcp80, Tcp443 ? Then will need IPS to detect & block it?
Any common services (python?) that uses GetHostbyName & on what Tcp ports they are listening on usually?
(if this makes sense)
"are external sources able to make calls to GetHost services/functions to Linux servers in our infra ie passing
thru firewall/IPS" ?
Does the question above make sense or it was mixed up with the case below:
http://security.stackexchange.com/questions/80498/can-an-executable-be-scanned-for-calls-to-the-vulnerable-glibc-ghost-functions
If it makes sense, does it go thru Tcp80, Tcp443 ? Then will need IPS to detect & block it?
Any common services (python?) that uses GetHostbyName & on what Tcp ports they are listening on usually?
(if this makes sense)
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Essence of the question is:
"are external sources able to make calls to GetHost services/functions to Linux servers in our infra ie remotely exploit this vulnerability ?
I've got a few answers from Trendmicro, F5 & Bluecat : it's only possible to
remotely exploit this vulnerability if we have EXIM mail service running.
Otherwise, one has to login to the Linux servers to be able to exploit it
"are external sources able to make calls to GetHost services/functions to Linux servers in our infra ie remotely exploit this vulnerability ?
I've got a few answers from Trendmicro, F5 & Bluecat : it's only possible to
remotely exploit this vulnerability if we have EXIM mail service running.
Otherwise, one has to login to the Linux servers to be able to exploit it
ASKER
I suppose in today's attacks, the attacks usually comes thru Tcp 80, Tcp443
& we can't block these 2 ports as they are needed.
Besides patching/updating glibc, is there any other workarounds to
mitigate this that you are aware of?
& we can't block these 2 ports as they are needed.
Besides patching/updating glibc, is there any other workarounds to
mitigate this that you are aware of?
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
It's change freeze period for next 1.5 months, so I'm exploring a no-downtime
workaround. Consider that only EXIM can be subject to remote exploitation,
this gives me a bit of time.
If there are dependencies issues (as I can't do 'yum update glibc' as our
servers are blocked from accessing Internet), can I just do
"rpm --nodeps -Uvh ./folder_holding_updated_r
workaround. Consider that only EXIM can be subject to remote exploitation,
this gives me a bit of time.
If there are dependencies issues (as I can't do 'yum update glibc' as our
servers are blocked from accessing Internet), can I just do
"rpm --nodeps -Uvh ./folder_holding_updated_r
Yes- all processes keep glibc open....
Your process of not installing security patches is flawed.
Your process of not installing security patches is flawed.
ASKER
Further question:
Can we "secure" or harden binaries tt I found to contain gethostbyname or
gethostbyname2 as interim mitigation as the link below indicates it's only those
2 functions:
http://security.stackexchange.com/questions/80498/can-an-executable-be-scanned-for-calls-to-the-vulnerable-glibc-ghost-functions