Re: [gentoo-user] Ghost cyber threat

2015-02-01 Thread Grant
 glsa-check is working fine, it was a slotted issue.  Still curious
 about a way to check for statically linked packages.

 There is no simple solution for this... USE flags static and
 static-libs handle cases where there is a choice between static and
 non-static version. In theory it is possible that some package
 (like boot loader helper) can be linked only statically, thus you
 will not be able to find it by USE flag. Though probability of this
 is very low, and due to a special nature of such binaries (or
 libraries) attack surface is even less.

 So you may assume your system reasonable secure if:
 - all GLSAs are applied;
 - there are no preserved libraries left (all packages using
 vulnerable libs must be rebuilt);
 - all static binaries and libraries depending directly or
 indirectly on vulnerable packages are rebuild;
 - there are no running processes using deleted files (reboot is a
 brute, but effective way to do this, otherwise one should grep lsof
 -n output for (deleted) files in use).


I think 'checkrestart' is a good substitute for this.


 - kernel should be updated to the latest version in branch if it is
 still supported, or upgrade to another branch, preferably LTS, if
 it is EOLed already.

 I have not seen GLSAs for kernel in ages, though old kernels
 definitely have serious security issues, and they may be far more
 serious than Ghost glibc bug.


I didn't know that, thank you.

- Grant



Re: [gentoo-user] Ghost cyber threat

2015-02-01 Thread Adam Carter

   Do they need telnet or ssh access,
 

 Not telnet shell but this could be triggered with telnet/nc or even nmap,
 hping, or tcpreplay - all of which could send an arbitrary payload to tcp
 or udp ports.

For clarity, its probably best to specify if we're talking about client or
server end. The original question was whether telnet or ssh access was
required, that is, does the attacker require access to the telnetd or sshd.
In GHOSTs case the answer is no, but if the attacker does have access and
an account, all they need to do is execute a local binary that uses the
older gethostbyname function rather than the newer getaddrinfo function,
and pass it a long hostname to lookup. However, in this case its considered
a local attack.

The attackers tool of choice (client end) will depend on personal
preference and the network service that provides the access for the attack.


Re: [gentoo-user] Ghost cyber threat

2015-01-31 Thread shawn wilson
On Jan 31, 2015 11:57 PM, Adam Carter adamcart...@gmail.com wrote:


  Do they need telnet or ssh access,


Not telnet shell but this could be triggered with telnet/nc or even nmap,
hping, or tcpreplay - all of which could send an arbitrary payload to tcp
or udp ports.

 I don't understand this obsession with ssh or telnet. Remote code
 execution means that malicious party can execute any code on
 affected system.


 To elaborate, since exim is an SMTP server it will be listening on
TCP/25. All the attacker needs to do is run an SMTP command that will
prompt exim to perform a lookup on a very long FQDN. The first command an
SMTP client issues to an SMTP server is 'HELO some FQDN'. Exim can be
configured to check if that the FQDN is valid, as a way of trying to
distinguish spammers from valid mail servers. So here we have a situation
where a security control happens to make the server less secure, and we
have all that's required for exploitation in a nice package.

Afaik, all remote attacks pretty much work the same. The example I'm sure
most of us have seen is with http (especially since shellshock - right? -
if not look up an example). You send a command to the server and then do
something it isn't expecting. You can also see this all the time with php
apps and options to do stuff in the app that wasn't intended. Half the time
http stuff is base64 encoded - that's fine since the server natively
decodes that.

So here you have an api call that does something unexpected - IIRC it was a
bounds issue. So once you figure out what the problem is, you look for apps
that make the call in a way that could trigger the bug. Then you compile
the program with debug symbols, step through it and try to trigger your
exploit. After you get it working there locally you figure out how to to
get that same bit of code to fire with that same malformed bit remotely.
You keep in mind that if you're going at something at the tcp level, the
packet still needs to be routed or broadcasted, and if you're going at
something at the application layer (most remote code is here) you need to
conform to the protocol until you're ready to trigger your evil bit (ie,
you generally want to say hi to someone before you go into an explanation
of how messed up they are - right?). Most services will end the connection
or just sit there erroring until some timeout or whatever unless you start
with their hi or a proper command. After that, have fun - you're on
someone else's system - whether you do something evil or not, their system
is processing what you sent -- is the whole point of everything else I
wrote and something worth remembering. Think of a shell as a REPL
(Wikipedia) and every other protocol as an interpreter waiting to execute
whatever you give it (or error out as most unfinished programs do).

As for this, there's multiple places an email server *might* want to verify
different positions of a domain. In the hello line, From, domainkey, etc.
If that vulnerable part of exim code is executed trying to check something
and you give it some evil bits (0s with 3 or less dots (.)), you might own
a free server.

HTH


Re: [gentoo-user] Ghost cyber threat

2015-01-31 Thread Adam Carter
  Do they need telnet or ssh access,

 I don't understand this obsession with ssh or telnet. Remote code
 execution means that malicious party can execute any code on
 affected system.


To elaborate, since exim is an SMTP server it will be listening on TCP/25.
All the attacker needs to do is run an SMTP command that will prompt exim
to perform a lookup on a very long FQDN. The first command an SMTP client
issues to an SMTP server is 'HELO some FQDN'. Exim can be configured to
check if that the FQDN is valid, as a way of trying to distinguish spammers
from valid mail servers. So here we have a situation where a security
control happens to make the server less secure, and we have all that's
required for exploitation in a nice package.


Re: [gentoo-user] Ghost cyber threat

2015-01-30 Thread symack
Hello Andrew,

Thank you for your response. For example, Exim implements reverse lookup.
How is malicious activity used against it? Do they need telnet or ssh
access,
or buy some freak of nature can exploit the vulnerability in other ways?

N
​


Re: [gentoo-user] Ghost cyber threat

2015-01-30 Thread Andrew Savchenko
Hi,

On Fri, 30 Jan 2015 10:11:52 -0500 symack wrote:
 Hello,
 
 From my understanding this is only an issue if a person is able to telnet
 or ssh
 to an effected system? Please confirm.

Are you talking about ghost issue or about GLSA I mentioned above?
If about ghost, then NO. Any applicaton using gethostbyname() or
gethostbyname2() and glibc-2.18 IS vulnerable.

Best regards,
Andrew Savchenko


pgp0memZyNaAg.pgp
Description: PGP signature


Re: [gentoo-user] Ghost cyber threat

2015-01-30 Thread symack
Just got the email in my box.​ Updating now


Re: [gentoo-user] Ghost cyber threat

2015-01-30 Thread Andrew Savchenko
On Fri, 30 Jan 2015 12:19:01 -0500 symack wrote:
 Hello Andrew,
 
 Thank you for your response. For example, Exim implements reverse lookup.
 How is malicious activity used against it?

Exim uses vulnerable function depending on its configuration, that's
why it may be possible to remotely execute code with privileges of
the exim process.

 Do they need telnet or ssh access,

I don't understand this obsession with ssh or telnet. Remote code
execution means that malicious party can execute any code on
affected system.

 or buy some freak of nature can exploit the vulnerability in other ways?

Considering how old one's setup should be to be affected to this
issue, it is likely that such systems have another vulnerabilities,
allowing attacker to gain root privileges even if exim itself is
being run as a non-root user.

Best regards,
Andrew Savchenko


pgpKpmns3wCDW.pgp
Description: PGP signature


Re: [gentoo-user] Ghost cyber threat

2015-01-30 Thread shawn wilson
On Jan 30, 2015 12:53 PM, Andrew Savchenko birc...@gentoo.org wrote:

 On Fri, 30 Jan 2015 12:19:01 -0500 symack wrote:

  or buy some freak of nature can exploit the vulnerability in other ways?

 Considering how old one's setup should be to be affected to this
 issue, it is likely that such systems have another vulnerabilities,
 allowing attacker to gain root privileges even if exim itself is
 being run as a non-root user.


Well, it's only a few days old on most distros.  It's about a year old on
Gentoo.  I think most of us run multiple boxes with some !gentoo. So most
of us had at least one box that was potentially vulnerable. Exim being the
only service proven vulnerable so far, it's possible you're otherwise fine.
OTOH, how would you like to find out a service you use is vulnerable to an
old bug? Especially one you had plenty of time to fix?

Again Gentoo has been fine unless for a while you stuck with an old version
for some reason. Most everything else...


Re: [gentoo-user] Ghost cyber threat

2015-01-30 Thread symack
Hello,

From my understanding this is only an issue if a person is able to telnet
or ssh
to an effected system? Please confirm.

N.
​


Re: [gentoo-user] Ghost cyber threat

2015-01-30 Thread Andrew Savchenko
On Thu, 29 Jan 2015 20:53:31 -0500 Rich Freeman wrote:
 On Thu, Jan 29, 2015 at 7:53 PM, Grant emailgr...@gmail.com wrote:
 
  glsa-check is working fine, it was a slotted issue.  Still curious
  about a way to check for statically linked packages.
 
 
 False positives in glsa data aren't unheard of - log those as bugs -
 vulnerable versions should be masked, and non-vulnerable versions
 shouldn't be flagged.  So, if an unmasked package is flagged, there is
 a bug of some kind that should be fixed.

It seems like glsa-check can't handle intervals at all. If package
have several intermittent intervals of vulnerable and fixed
versions, e.g. multiple slots fix fixes in several slots,
glsa-check fail:
https://bugs.gentoo.org/show_bug.cgi?id=106677

Quite an old bug...

Best regards,
Andrew Savchenko


pgpAydWkL9zJS.pgp
Description: PGP signature


Re: [gentoo-user] Ghost cyber threat

2015-01-29 Thread Grant
 Does anybody know more about this security flaw in the open-source Linux
 GNU C Library

 http://www.theglobeandmail.com/technology/linux-makers-release-patch-to-thwart-new-ghost-cyber-threat/article22662060/?cmpid=rss1


I updated a system of mine that was using an old version of glibc and
rebooted.  I can't do a full emerge world there or use various other
portage tools due to the peculiarities of my current situation.  Could
I still be vulnerable?

- Grant



Re: [gentoo-user] Ghost cyber threat

2015-01-29 Thread Andrew Savchenko
On Thu, 29 Jan 2015 08:52:57 -0800 Grant wrote:
  Does anybody know more about this security flaw in the open-source Linux
  GNU C Library
 
  http://www.theglobeandmail.com/technology/linux-makers-release-patch-to-thwart-new-ghost-cyber-threat/article22662060/?cmpid=rss1
 
 
 I updated a system of mine that was using an old version of glibc and
 rebooted.  I can't do a full emerge world there or use various other
 portage tools due to the peculiarities of my current situation.  Could
 I still be vulnerable?

Your system may be vulnerable to this issue only if you have
packages statically linked with vulnerable glibc libs, so most
likely — no. But your system may be affected by a plenty of other
issues in various packages.

At the very least you should apply all GLSAs to your system: while
they don't encompass all vulnerabilities, they should warn you
about most common and important ones.

Best regards,
Andrew Savchenko


pgpMWQmbZaBhp.pgp
Description: PGP signature


Re: [gentoo-user] Ghost cyber threat

2015-01-29 Thread Grant
  Does anybody know more about this security flaw in the open-source Linux
  GNU C Library
 
  http://www.theglobeandmail.com/technology/linux-makers-release-patch-to-thwart-new-ghost-cyber-threat/article22662060/?cmpid=rss1


 I updated a system of mine that was using an old version of glibc and
 rebooted.  I can't do a full emerge world there or use various other
 portage tools due to the peculiarities of my current situation.  Could
 I still be vulnerable?

 Your system may be vulnerable to this issue only if you have
 packages statically linked with vulnerable glibc libs, so most
 likely — no. But your system may be affected by a plenty of other
 issues in various packages.

 At the very least you should apply all GLSAs to your system: while
 they don't encompass all vulnerabilities, they should warn you
 about most common and important ones.


I don't think I have USE=static anywhere.  Any way to confirm?

I've been watching glsa.gentoo.org (a little dismayed that this glibc
vulnerability isn't there yet) but you prompted me to give glsa-check
a try.  It's telling me I'm vulnerable to some that I clearly am not
vulnerable to.  Do I need to clear a cache somewhere?

- Grant



Re: [gentoo-user] Ghost cyber threat

2015-01-29 Thread Grant
  Does anybody know more about this security flaw in the open-source Linux
  GNU C Library
 
  http://www.theglobeandmail.com/technology/linux-makers-release-patch-to-thwart-new-ghost-cyber-threat/article22662060/?cmpid=rss1


 I updated a system of mine that was using an old version of glibc and
 rebooted.  I can't do a full emerge world there or use various other
 portage tools due to the peculiarities of my current situation.  Could
 I still be vulnerable?

 Your system may be vulnerable to this issue only if you have
 packages statically linked with vulnerable glibc libs, so most
 likely — no. But your system may be affected by a plenty of other
 issues in various packages.

 At the very least you should apply all GLSAs to your system: while
 they don't encompass all vulnerabilities, they should warn you
 about most common and important ones.


 I don't think I have USE=static anywhere.  Any way to confirm?

 I've been watching glsa.gentoo.org (a little dismayed that this glibc
 vulnerability isn't there yet) but you prompted me to give glsa-check
 a try.  It's telling me I'm vulnerable to some that I clearly am not
 vulnerable to.  Do I need to clear a cache somewhere?


glsa-check is working fine, it was a slotted issue.  Still curious
about a way to check for statically linked packages.

- Grant



Re: [gentoo-user] Ghost cyber threat

2015-01-29 Thread Rich Freeman
On Thu, Jan 29, 2015 at 7:53 PM, Grant emailgr...@gmail.com wrote:

 glsa-check is working fine, it was a slotted issue.  Still curious
 about a way to check for statically linked packages.


False positives in glsa data aren't unheard of - log those as bugs -
vulnerable versions should be masked, and non-vulnerable versions
shouldn't be flagged.  So, if an unmasked package is flagged, there is
a bug of some kind that should be fixed.

Glsa's aren't sent out right now until the last arch is stable.

-- 
Rich



Re: [gentoo-user] Ghost cyber threat

2015-01-29 Thread Andrew Savchenko
On Thu, 29 Jan 2015 16:53:43 -0800 Grant wrote:
 glsa-check is working fine, it was a slotted issue.  Still curious
 about a way to check for statically linked packages.

There is no simple solution for this... USE flags static and
static-libs handle cases where there is a choice between static and
non-static version. In theory it is possible that some package
(like boot loader helper) can be linked only statically, thus you
will not be able to find it by USE flag. Though probability of this
is very low, and due to a special nature of such binaries (or
libraries) attack surface is even less.

So you may assume your system reasonable secure if:
- all GLSAs are applied;
- there are no preserved libraries left (all packages using
vulnerable libs must be rebuilt);
- all static binaries and libraries depending directly or
indirectly on vulnerable packages are rebuild;
- there are no running processes using deleted files (reboot is a
brute, but effective way to do this, otherwise one should grep lsof
-n output for (deleted) files in use).
- kernel should be updated to the latest version in branch if it is
still supported, or upgrade to another branch, preferably LTS, if
it is EOLed already.

I have not seen GLSAs for kernel in ages, though old kernels
definitely have serious security issues, and they may be far more
serious than Ghost glibc bug.

Best regards,
Andrew Savchenko


pgpgafG4_tW6U.pgp
Description: PGP signature


Re: [gentoo-user] Ghost cyber threat

2015-01-28 Thread Rich Freeman
On Tue, Jan 27, 2015 at 7:25 PM, Philip Webb purs...@ca.inter.net wrote:

 I'm running 2.19-r1 , installed 140802 ; vulnerable are  2.18 .

 Linux systems are at risk only when admins don't keep versions upto-date.

Unless the patch was backported, distros like debian stable are
potentially vulnerable.  Gentoo should be fine unless you haven't been
keeping up with updates for quite a while.

-- 
Rich




Re: [gentoo-user] Ghost cyber threat

2015-01-27 Thread Philip Webb
150127 Joseph wrote:
 Does anybody know more about this security flaw
 in the open-source Linux GNU C Library : 
 http://www.theglobeandmail.com/technology/linux-makers-release-patch-to-thwart-new-ghost-cyber-threat/article22662060/?cmpid=rss1

Acc to this, it was patched 2013  today threatens only long-term systems :

http://threatpost.com/ghost-glibc-remote-code-execution-vulnerability-affects-all-linux-systems/110679

I'm running 2.19-r1 , installed 140802 ; vulnerable are  2.18 .

Linux systems are at risk only when admins don't keep versions upto-date.
My netbook was running 2.15-r3 (121216) till I updated it this week
(I haven't used it since 130127  ordinarily don't use it for I/net).

-- 
,,
SUPPORT ___//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT`-O--O---'   purslowatchassdotutorontodotca