Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 9 replies
  • Subscribers 3 subscribers
  • Views 3046 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Vulnerabilities in Astaro Security Linux

mattd
FYI from Securityfocus...

-----Original Message-----
From: Joerg.Luebbert@t-online.de [mailto:Joerg.Luebbert@t-online.de]
Sent: 02 February 2002 18:40
To: bugtraq@securityfocus.com
Subject: Vulnerabilities in Astaro Security Linux 2.016


Preamble:

Product: Astaro Security Linux

Version: 2.016

Vendor: Astaro AG

Vendor URL: http://www.astaro.com

Vendor status and reply: Vendor has been contacted with posting of this 
message

Description:
Astaro develops and distributes the firewall solution Astaro Security 
Linux. Astaro Security Linux offers extensive protection for local 
networks against hackers, viruses and other risks of connecting to the 
Internet. Astaro Security Linux is distributed by a worldwide network of 
partners who offer local support regarding installation and maintenance.

Introduction:
Dear BugTraq readers. I've taken a short glimpse on Astaro Security 
Linux and found out some points of interest that are mostly design 
flaws. Please note that I am theorising (based on a 1 1/2 hour research 
only) about the impacts and have not proven their concepts on Astaro 
Security Linux yet even though most can be proved easily.

Some of the vulnerabilities might be local and some might argue about 
that Astaro Security Linux is a Firewall and no server... but as it uses 
SSHD it could always be that the "loginuser" account might have been 
compromised and shell access granted.

Vulnerabilities:

Summary:
5 Design flaws
2 Completely theorised design flaws
1 Possible design flaw
1 Licensing violation
1 Software bug

Category 1: Design flaw

Problem 1:
Astaro Security Linux chroots various daemons like snmpd and named in an 
insecure manner. The proc filesystem is mounted within their chroot 
jails. Furthermore the chroot jail entitled chroot-ipsec provides the 
proc file system, a bash, ls, cat and most notably mount.

Impact 1:
Arbitrary users could cause severe damage by breaking the named or snmpd 
remotely and by misusing the proc file system to reconfigure certain 
parts of the system configuration under proc/sys. Furthermore proc/kcore 
could be read to obtain information stored in memory which could lead to 
system administrator privileges. These could for instance be DES 
encrypted passwords which leads to another design flaw

Exploit 1: None provided

Category 2: Design flaw

Problem 2:
Astaro Security Linux uses the DES algorithm as standard hashing scheme. 
DES has turned very old and is known to be easily crackable with modern 
processing power.

Impact 2:
Arbitrary users who obtain encrypted passwords (see 1) could retreive a 
6 letter clear-text password within just some hours using modern 
processing power and use it to compromise the system.

Exploit 2: None provided

Category 3: Design flaw

Problem 3:
Astaro Security Linux runs most of its daemons with UID 0 privileges. 
Affected daemons are: named or snmpd. These daemons run in a chroot jail.

Impact 3:
Arbitrary users could remotely crack one of the affected daemons and use 
UID 0 powers to compromise the whole file system even if these daemons 
run in a chroot jail.

Additional note 3-1:
The main design flaw lies within that these daemons run UID 0 within a 
chroot jail. The daemons itself are not the design flaw (even though 
BIND 8.2.3 can be considered old).

Additional note 3-2:
Other daemons with UID 0 are syslogd, klogd, mdw_daemon.pl, cron, aua 
and sshd. VPN subsystem, SQUID and others haven't been checked by me.

Exploit 3: None provided

Category 4: Possible design flaw

Problem 4:
OpenSSL PRNG Internal State Disclosure Vulnerability

Impact 4:
Please see: http://www.securityfocus.com/bid/3004

Exploit 4: None provided

Additional note 4:
It was NOT tested if the version of OpenSSL (0.9.6) used in Astaro 
Security Linux is a security-patched version of OpenSSL 0.9.6 since no 
sources were provided (5)

Category 5: Licensing violation

Problem 5:
Astaro AG releases software packages without providing their sources and 
modifications to them as required in §3 of the GNU GPL and neither seems 
to offer distribution of GPL sources for free within a 3 year period in 
a written form.

Additional note 5:
I have not checked every available documentation for a written form of 
an offer as described in GNU GPL §3 b but only their license (which 
should normally contain just that) and CD-ROM contents.

Category 6: Design flaw

Problem 6:
Astaro Security Linux has a default limit for simultaneously processes 
of 8190 soft and 8912 hard and its default cpu-time is "unlimited".

Impact 6:
Arbitrary users with local access (loginuser) can easily launch fork 
bombs to consume 100% CPU power and stop the system from operating.

Exploit 6: None provided

Category 7: Completely theorised design flaw

Problem 7:
Astaro Security Linux uses a very old version of PAM (0.70 dated 
09.10.1999) which maybe contains vulnerabilities.

Category 8: Design flaw

Problem 8:
/proc/version indicates "Linux version 2.4.8-asl-0.010815.0", which 
indicates the 2.4.8 version of the Linux kernel that contains some 
security vulnerabilities. Additional information on possible 
vulnerabilities can be found here:

http://www.securityfocus.com/bid/3570
http://www.securityfocus.com/bid/3418
http://www.securityfocus.com/bid/3444
http://www.securityfocus.com/bid/3505

Impact 8: Various, see above URLs.

Exploit 8: None provided

Additional note 8:
Due to absence of source code it could not be proved if this kernel is 
patched against the security issues mentioned above.

Category 9: Completely theorised design flaw

Problem 9:
Astaro Security Linux seems to rely on an old version of glibc according 
to ls -l /lib/libc*.

Output: -rwxr-xr-x   1 root     root      1080268 Sep 15  2000 libc.so.6

If my assumption is correct and the version used was not patched, it 
could be possible that the system is vulnerable to a "glibc file 
globbing heap corruption vulnerability". For more information please 
see: http://www.securityfocus.com/bid/3707

Impact 9: See URL above

Exploit 9: None provided

Category 10: Software bug (OT for Bugtraq, still included  [;)] 

Problem 10: During installation one can choose to install OpenSource 
software only or OpenSource software and the so called Astaro Security 
Enterprise Toolkit. When only "OpenSource" was chosen, the installer 
locks up after entry of the last password (I think this was for lilo). 
If my assumption is right (that a lilo password is asked for) then no 
lilo password will be set even though the Enterprise Toolkit was 
selected and the installation finished successfully.

Additional note 10:
System tested on was 800MHZ Duron, 128MB RAM, 20GB Maxtor HD, 52X 
CD-ROM, 3X RTL 8139.

Final words:

Conclusion, a final word to the Astaro AG:
So much about a "Security Linux"... You may have done the firewalling and 
the configuration interface of your product real good... but you should 
also read some articles on what could be considered more internal 
security and work on your products some more.

Disclaimer:
None of the information provided are meant to aid any destructive 
purposes. I will furthermore take no responsibility for that anyone will 
use the information provided for his or her own malicious purposes. This 
information is intended to aid in improving the current state of Astaro 
Security Linux, warn companies and individuals who run Astaro Security 
Linux and should help other designers of Linux distributions to avoid 
flaws like the ones elaborated on above. Please also not that I am in no 
way affiliated with Astaro AG or any of their 3rd party affiliates or 
want to harm Astaro AG and/or their customers.

- Jörg Lübbert (aka Kaladis)

-- 
Kaladix Linux - The Secure Linux Distribution
URL: http://www.kaladix.org


This thread was automatically locked due to age.
Parents
  • 0
    Hello,

    Could we have a reassuring reply from the Astaro team concerning those potential vulnerabilities ?

    Thanks.
  • 0 in reply to Frediz
    Hi there,

    thankyou for the feedback, we will fix the relevant issues in Up2Date 2.021, which will be out really soon.
     
    All Astaro users please note, that some of the mentioned issues are pretty theoretical and none of them contain any remote vulnerabilities.
     
    When you didn't give away your passwords or keys, there is no decrease of security of your firewall solution at all.
     
    Best Regards,
    Jan Hichert

    [ 06 February 2002: Message edited by: Jan Hichert ]

  • 0 in reply to Jan Hichert
    > none of them contain any remote vulnerabilities.

    That is not quite true.

    Problem 1, 3, 4 and maybe 7 are remote vulnerabilities whereas 1 and 3 are remote only.

    1 and 3 means that the services (the dns for example) are run in an insecure manner that can lead to gaining remote root on an Astaro system. These design flaws will only work if the daemon/service itself has a vulnerability. I haven't checked for that yet. Chances are that if the daemons are quite old in version / date there could be an exploit ready for them. And since 2.0.16 is getting old it is actually likely. I could tell you guys more specifically but I haven't  installed it anymore. Maybe one of the users might want to test the DNS, snmpd and other daemons for their version "named -v" for BIND (DNS) and compare the versions against entries in securityfocus.com to determine the impact.

    4) affects daemons compiled against OpenSSL (The webserver [mod_ssl]). It is possible to predict the "randomness" that is used for cryptographic data-transfer through that hole leading to weak cryptography.

    > When you didn't give away your passwords or keys, 
    > there is no decrease of security of your firewall 
    > solution at all.

    again wrong, see above  [;)]
  • 0 in reply to Joerg Luebbert
    Hi, sorry, but I just reposted this same topic on another thread, it seems that I didn't catch this thread before posting mine.....
Reply Children
  • 0 in reply to Raúl Millán
    Hi,
     
    I played around with several security distros including Astaro (which I dont prefer, but its nice), and I am reading this newsboard for quite a while.
     
    Some design issues Jorg Lubbert mentioned are reasonable, but most of them are hot air. Cut'n paste bugtraq just isn't enough to issue serious security statements.
     
    I don't know if Astaro is issueing a technical statement on this, but for example Jorg didn't even recognize that the bind is protected by Kernel capabilities.
     
    To me this looks like a clumsy way of promoting his own distro.
     
    Regards,
    Sven
  • 0 in reply to SvenM
    btw, 

    * snmp isnt reachable from remote at all
    * according to http://www.isc.org/products/BIND/bind-security.html the used bind version isnt vulnerable
    * from http://www.securityfocus.com/cgi-bin/vulns-item.pl?section=discussion&id=3004: "No vulnerable applications are currently known."

    where is the problem?
  • 0 in reply to lop
    Hello,

    As mentioned in my advisory I only did very fast research on the issues and wrote down what I found. Please note the difference between "design flaw" and "vulnerability". As seen in my advisory I reported design flaws and no actual vulnerabilities (and sorry for the subject line, it should have read "design flaws" but I forgot to change it).

    I did not intend to promote my distro with this. For my protection I could tell you a lot of arguments, I'll state 3 now.

    A) You can't even download it yet so why should I advertise it?
    B) I was looking into Astaro because I was asked to set up a firewall distro with easy web interface for a company and for no other reason.
    C) I'm doing a server distro, Astaro is doing a firewall distro. Two different pair of shoes and target groups.

    I guess the next time I post something on BugTraq I'll do deeper analysis of the issues prior to posting it so you people won't scold me anymore  [;)] 

    - Jörg
  • 0 in reply to Joerg Luebbert
    Joerg-

    I think it's good that you have pointed out improvements for the product (particularly the chroot issues); it's better now for it, and all customers of Astaro benefit. But I must take issue with a few points you make:

    1) The PAM version: "...maybe contains vulnerabilities" (maybe??!!). How often have all of us been bitten by using a recent version of software which has a greater level of functionality in it, along with a greater amount of code, which has a greater degree of complexity and, we find out at a later date, associated vulnerabilities? If they do not need any of the functionality of the more recent PAM module innovations, what is the point? Unless you can cite a specific vulnerability in the version they are using...

    2) GNU license violation: can you point to a specific executable or hardlinked code component that uses GNU code which they don't publish as source in their publicly available distro??

    3) potential loginuser resource exploit: hey, I've got one for you: what if root is compromised? I think the focus should be upon much more likely scenarios, namely a code component like a proxy or operating system component which can fail, or is plainly configured wrong (such as the proc access you pointed out). In a corporate environment with a few thousand transactions going on, each possibly having a few processes, though not a common configuration, might fail with limits such as you are contemplating. I do think this point merits discussion, but I don't think it should be included in a ~"things they're doing wrong" document.

    Did you discuss (or seriously attempt to discuss) these points with Astaro staff? If you had, they might have saved you the trouble of publishing these non-issues, and you still could have gone gotten credit for posting the substantial ones immediately after discussion with them...
  • 0 in reply to Another Steve
    Hello Steve,

    You're right with your point about PAM. Indeed it's a two sided blade. If you use old versions it could be that all vulnerabilities are gone, but it could also be that new ones were discovered (and that security patches were not applied). Well as long as they're keeping up-to-date with the patches it's perfectly fine and I shouldn't really have mentioned it... But I couldn't tell if they applied patches or not, after all, no source was there.

    The majority of code in Astaro Linux is GNU code. In particular programs such as ls or mount are, grep, which and whatnot are GNU as well.

    And about 3. The only account with higher limits should be root. I see no need for the loginuser to have 8000 processes. And after all, I don't think that the daemons used in Astaro spawn (a lot of) child-processes at all.

    I haven't discussed any of the issues with Astaro. I just wrote up that document and sent to them via email. It would have been better to discuss everything with Astaro and do more research on the issues. The problem is that I just don't have the time to do that and the problem would get fixed this way or another.
Unfiltered HTML