Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Security

SDSC Secure Syslog 100

Posted by michael from the footprints-in-the-snow dept.
Wee writes "I saw this morning that the San Diego Supercomputer Center has released Secure Syslog, a replacement for the standard Linux/UNIX syslog daemon they've been working on for some time. It adds security and performance features (modular design, highly scalable), while retaining backwards compatibility. According to their announcement, it is the first syslog implementation to target "syslog-reliable" (RFC 3195) functionality and it is the first syslog targeted at very high performance and forensically-sound auditing. It's currently under the UC's "free for non-commercial use" license, but they are looking at moving to a completely open license (BSD-style licensing was mentioned). If you have high-traffic systems and you need reliable syslogging, this might be a worth a look. Those needing syslogging over TCP/BEEP, sockets, etc as well as UDP might also want to check it out."
This discussion has been archived. No new comments can be posted.

SDSC Secure Syslog More

SDSC Secure Syslog

Comments Filter:
  • If it's meant for high-traffic zones, why would it be currently available for non-commercial use first? Ah, I get it, yet again using the public as guinea pigs. You know Gates has to be behind this one. (last part of comment meant to be humerous)

  • I smile whenever ancient Unix utils are updated (Score:5, Funny)

    by Frothy Walrus ( 534163 ) on Thursday December 05, 2002 @01:09PM (#4819189)
    ...like syslog, for instance. Very extensible, appropriately hieroglyphic configuration, arbitrary manner of operation... it had everything a successful Unix daemon needs.

    Except security. Welcome to the 21st Century, syslog.
  • huh?

  • TCP/BEEP (Score:5, Informative)

    by zephc ( 225327 ) on Thursday December 05, 2002 @01:10PM (#4819201)
    FYI, this is BEEP [codefactory.se]

    No, it's not Captain Pike's YES/NO beeps

  • free for non commerical use, aka... (Score:4, Insightful)

    by ostiguy ( 63618 ) on Thursday December 05, 2002 @01:10PM (#4819204)
    free for slow adoption.

    the sooner more people can use it, the sooner corporate products will have to support it, and the more secure we all can hopefully be.

    after all, we haven't had much luck getting the newer snmp versions deployed.

    ostiguy

  • Hmm...forensically-sound auditing (Score:4, Funny)

    by carl67lp ( 465321 ) on Thursday December 05, 2002 @01:12PM (#4819225) Journal
    I suspect that many of the top corporations may find a use for this in wake of all of the "Oops, I lost that important file!" scandals, and the need to trace steps of hackers too.

    I see a great future in this and the products that come after it. Kudos to the developers!
    • Actually many top corporations are getting very serious about destroying documents that are no longer needed/required to be kept. Still, the log would be useful for showing that the file existed, was kept for the required time period, and purged afterward.
  • I've been looking for just this and all that I have been able to come up with are funny, unsupported hacks that lack backwards compatibility. This looks perfect! Now, will it compile without any changes under HP-UX?

    • Re: HP-sUX (Score:5, Funny)

      by Anonymous Coward on Thursday December 05, 2002 @01:27PM (#4819336)
      Now, will it compile without any changes under HP-UX?
      Sure, as long as you use gcc, and not HP's unbelievably expensive supposedly "ANSI" compiler, or the dreaded brain-dead K&R compiler that comes free with HP-UX.
      And as long as you remember root can't have any shell other than /sbin/sh.
      And of course you understand the next maintenance pack from HP will contain a depot that will overwrite key libraries without warning and break the thing completely.
      In short, it works just as well on HP-UX as anything else does.
      Feel my pain. I admin many large HP-UX machines.
      • > Feel my pain. I admin many large HP-UX machines.
        I can feel your pain soooo good...

      • Feel my pain. I admin many large HP-UX machines.

        To quote Bill (the Cat) "BLLLLFFFTTT"

        If you want Pain then try using AIX...

        I do remember seeing a piece of advice for those wishing to become System Administrators...

        Find an OS that you hate... Congratulations, you will be working with it for the rest of your life.

        After Solaris, I thought HP-UX was bad... Not awful, but bad... Now I deal with AIX...

        Z... Admin of AIX, HP-UX, Solaris and Linux boxes... I try to forget the SCO machines.

  • TCP syslogging already available (Score:5, Interesting)

    by The Blue Meanie ( 223473 ) on Thursday December 05, 2002 @01:19PM (#4819279)
    If you need syslogging over TCP and want a *way* more configurable system for filtering syslog destinations, including regex filtering and per-host routing, you might want to look at syslog-ng [balabit.hu]. It works great for me, and is already GPL'ed, so no waiting for a license change.

    • Re:TCP syslogging already available (Score:4, Informative)

      by Emrys ( 7536 ) on Thursday December 05, 2002 @02:05PM (#4819575)
      secure-syslog isn't just about TCP, it's about 100% reliability in high high volume environments. Nothing out there right now can do that. When I talked to these guys at the 2002 Usenix Security Conference, they were targeting environments that wanted to run IIS/Apache weblogs over syslog for hundreds or thousands of hosts, without ever dropping a line. The regex stuff is left out because a) other tools can already do it better (the Unix way) and b) it doesn't directly help the goal of reliability in high-volume environments (which requires speed among other things) and therefore is bloat that would likely hurt that goal.

      I've been anxiously waiting for this announcement since then. Too bad about the license; hopefully they get it fixed soon.
    • syslog-ng is nice, it has the advantages of TCP and a smart filtering scheme, but that's all. For example, logging to SQL is very weak, it's more like a hack.
      For example, a syslog version that does everything syslog-ng does, and more, and has decent SQL logging, and a sound security mechanism (PEO) is msyslog [sourceforge.net]
      However, even msyslog is quite simplistic when compared to sdscsyslog. IMO, sdscsyslog has an extremely intelligent architecture, that allows for easy expansion, and easy implementation of features that neither syslog-ng nor msyslog can dream of.
      • I dearly wish one of those would solve the syslog problem, but...

        msyslog:
        Docs? Example of how to set it up, pretty please? To clearify, setting msyslog up as a straight 415/udp syslog replacement is decently easy, but setting PEO or mysql support up is near impossible, couple that with the fact the developer (phreed) seems to have almost no time to do anything with the project kills this for serious sites.

        syslog-ng:
        MUCH better docs that msyslog, but adding mysql support is mostly a hack, and the config setup is about as cryptic as the old sendmail config. That coupled with the fact that I've YET to get it syslog-ng to send messages to a remote host correctly over TCP(recieve yes, but send no), knocks this off my list.

        I for one will be grabbing a copy of SDSC Secure Syslog pretty quick. We use a centralized logging setup, and neither syslog-ng, nor msyslog fulfills our needs. (nor does nsyslog, or mbsyslog, nor Metalog, we didn't bother looking at DJB'd tools since his restrictive license could be a problem with sending out updates to logging sites).
        • Well, msyslog works fine with SQL, provided that you don't miss these steps:
          - create the appropriate table structure
          - configure msyslog to use the tables you created
          - configure SQL to let msyslog have enough permissions to write to the tables
          The first two are in the man pages (om_mysql and the conf file format), the latter in the SQL server documentation.
          Works like a charm.

  • Re: replacement (Score:3, Insightful)

    by bogie ( 31020 ) on Thursday December 05, 2002 @01:24PM (#4819320) Journal
    "a replacement for the standard Linux/UNIX syslog daemon they've been working on for some time....it's currently under the UC's "free for non-commercial use" license, but they are looking at moving to a completely open license (BSD-style licensing was mentioned)."

    Sorry to sound like a weenie, but if its not GPL'd I'm not interested. This is one of those "core parts" I'm usually talking about that needs to be gpl if its going to get included in every distro. I know there are important parts of every linux distro that aren't GPL, but the more software we add that isn't GPL the worse off we are. Don't get me wrong, I'm all for proprietary add-on software(desktop/server apps, games etc) for linux, but the core software, ie base OS, system utilities, desktop WM, internet browser/connection software and basic office capabilities need to be GPL.

    • Re: replacement (Score:1, Interesting)

      by Anonymous Coward
      as a software developer at UCSD/SDSC I know it can be very difficult to get the folks in the UCSD offices to agree to GPL. Difficult, but not impossible. I would expect that it will happen eventually. :) (way to go team!)
    • What do you use for webserving?

      What about database service? MySQL has poor functionality in the fully-GPL version, and PostgreSQL is BSD-licensed.

      Either you're an idiot or you're trolling. There is no in between. Personally, I think you're an idiot.

      • Re:Apache is not GPL (Score:5, Insightful)

        by FreeUser ( 11483 ) on Thursday December 05, 2002 @01:56PM (#4819519)
        What do you use for webserving?

        He probably uses apache, although he could be using any one of several free webservers, some of which are in fact GPLed.

        Either you're an idiot or you're trolling. There is no in between. Personally, I think you're an idiot.

        It is a pity you make such a good point about the diversity of free software licenses available, then ruin it with that sort of inane flamage.

        First, he may or may not be trolling. I suspect probably not (but I could be wrong) ... his comment appears to be a more naive equation of Free Software==GPL, which of course is mistaken, as you correctly point out. Free software can be public domain, it can be BSD licensed, it can be Artistically licensed, it can be apache licensed, it can be LGPLed, indeed, it can be licensed under any number of such licenses.

        Second, to say there is no in between is foolish. Almost as foolish as Dubya's "your with us or you're with the terrorists," which the Iranians quite correctly rebutted with "we are neither with you, nor are we with the terrorists, and you sir are a pathetic simpleton" (a nuance obviuosly lost on our current regime). There is a huge middle ground ... people often say provactive things in making very valid points.

        Finally, he is hardly an idiot. Naive in equating the GPL with free software, but had his comment replaced the term GPL with "free software" it would have been very valid and on point. The core UNIX utilities and operating system need to be free software, unencumbered by constraints such as "no commercial use" (or the asinine "no use to violate human rights", where the definition of human rights varies from county to county, state to state, and very obviuosly nation to nation). On that point he is correct ... he simply needs to educate himself on the nuances of free software licenses, and the difference between free software and the GPL, which is merely a subset thereof. Hardly a sign of idiocy, merely a sign of ignorance, a condition that is easily corrected.

    • Re: replacement (Score:1, Offtopic)

      by addaon ( 41825 )
      Why?

    • Don't get me wrong, I'm all for proprietary add-on software(desktop/server apps, games etc) for linux

      Yeah, the BSD license is so very proprietary. So proprietary, in fact, that you can take BSD-licensed code, modify it, and release the result under GPL. Doesn't get much more non-free than that.

      Sheesh, the GPL zealots never fail to astound me...

  • Remote logging exists right now (Score:3, Informative)

    by bigberk ( 547360 ) <bigberk@users.pc9.org> on Thursday December 05, 2002 @01:26PM (#4819328)

    Set up a locked down host on your network (no services running) except for syslogd. Then other hosts can use remote logging to log to this host. In case of even a widespread system compromise, your locked down logging host is completely safe and your logs can be obtained through console login.

    See section "SUPPORT FOR REMOTE LOGGING" in man syslogd.

  • Brazil (Score:4, Interesting)

    by SWroclawski ( 95770 ) <serge@wrocLIONlawski.org minus cat> on Thursday December 05, 2002 @01:31PM (#4819360) Homepage

    Wow did anyone else notice the Brazil [imdb.com] references in RFC 3195?

    It's good to know that geek culture still persists and can perimate into even the most serious subjects.

    - Serge Wroclawski

    • no, perhaps you could explain it to the rest of us, or at least what page you found teh joke on. then we may revel in your humor.
      • If you saw the movie (Brazil) and bothered to read the RFC, you'll see that the messages passed and fdqns have many references to the film.

        If you didn't see the film or read the RFC, I'm afraid I can't help you...

        Unless you fill out the correct form and get it stamped.

        - Serge Wroclawski

        • Re:Brazil (Score:4, Funny)

          by Bazman ( 4849 ) on Thursday December 05, 2002 @01:54PM (#4819500) Journal
          And with TCP/IP being a reliable transport medium, there's no chance of 'Tuttle' becoming 'Buttle'! [*]

          We've named one of the forms we use in our department a 27B/6 in honour of the film. We refuse to buy any equipment until someone has filled one in.

          Baz

          [*] part of the plot of the film is that Mr Buttle gets mistakenly arrested instead of Mr Tuttle because a swatted fly falls into the machines that are typing out names of people to be arrested.
        • Here's an example from the RFC:

          L: MSG 1 0 . 0 50
          L:
          L: Central Services. This has not been a recording.
          L: END
          I: ANS 1 0 . 0 61 0
          I:
          I: Oct 27 13:21:08 ductwork imxpd[141]: Heating emergency.END
          I: ANS 1 0 . 61 58 1
          I:
          I: Oct 27 13:22:15 ductwork imxpd[141]: Contact Tuttle.END
          I: NUL 1 0 . 119 0
          I: END
  • ... to help your ISP to maintain massive logs of your online activities, neatly packaged for law enforcement and other "authorities".

    Thanks!

    • <sarcasm>
      That makes me feel more secure... I mean, now, I don't have to worry about whether I should clean up the logs or not. It's not an option. One less thing to worry about.
      </sarcasm>

      Then again, the hardest thing about finding a needle in a haystack isn't sorting out the hay. You really have a tough time finding a needle in a bunch of other needles.. --er, log entries.

  • Buzzwords galore! (Score:5, Funny)

    by stratjakt ( 596332 ) on Thursday December 05, 2002 @01:36PM (#4819391) Journal
    Modular!

    Scalable!

    Backwards compatible!

    Linux!

    RFC 3195 functionality!

    high performance!

    forensically-sound auditing!

    If only it was vertically integrated. Oh well, better luck next time!

    till then, /dev/null is all the syslog I need!

  • Several problems with syslogd. (Score:5, Interesting)

    by defile ( 1059 ) on Thursday December 05, 2002 @01:37PM (#4819397) Homepage Journal

    Standard syslog has several problems which I think are quite serious.

    • Remote logging is a joke. There is no authentication, and no notification whatsoever that the event was received by the remote syslog daemon. An attacker can fill the remote syslog with garbage data if they so choose.

    • The records are entirely unstructured and not validated. The timestamp, hostname, and process id are all volunteered by the application, not something that's noted by syslogd.

    • There is no guarantee whatsoever that an application that has called syslog() will have its messages safely recorded when the function returns. I'm not talking safely tucked away on disk if the system crashes, but even written into the buffer cache by syslogd when syslog(3) returns. See end of post for details.

    • If syslog's receive buffer is full, syslog(3) will block. This means that if syslogd cannot keep up with the rate of messages, which is a really easy condition to find yourself in given that by default syslogd calls fsync() after every log file update, your system will slow to a crawl. You cannot even login(1) since most systems record this activity to security logs.

    P.S. syslog() returns as quickly as possible. Try an experiment. Generate a random number, call syslog() with this number as a string, and then open() /var/log/messages, seek to the end minus 4096 bytes. Try to find the random number. I have tried it 20 times and never has the number been there by the time read() was called. It takes longer than an application doing syslog()/open()/lseek()/read() for syslogd to record it into to the buffer-cache, let alone fsync() it to disk.

    • Valid points, all. Keep in mind, though, that the syslog protocol runs on all sorts of systems, not just servers. It is still true that a simple, UDP-based protocol is easier on embedded hardware than a complex, TCP-based one.

      Also, the function of syslog is not only to log routine diagnostic messages but also "distress calls", where the ailing system may only be able to squirt a few bytes onto the network before dying. Formatting, handshakes and authentication are all potential obstacles.

      I think that a reliable syslogd is very important, for the reasons you mentioned and more. Sometimes the data recorded by standard syslogd is useless, making its design a liability. But its simple design helped ensure its acceptance. See RFC 3164 [ietf.org] for historical notes and a review of the syslog protocol--section 1 is of great relevance.

    • by default syslogd calls fsync() after every log file update


      This behavior should be disabled, when possible, because the security gain is mostly imaginary -- it's rare for a system to fail such that buffers aren't flushed, yet you still have time to explicitly sync -- while the performance hit is not.

  • Here's the UC license that comes with it (Score:5, Informative)

    by Wee ( 17189 ) on Thursday December 05, 2002 @01:46PM (#4819445)
    I don't need the karma or anything, but I've seen a lot of people mention (deride) the license under which the software was released. No, it's not GPLed, BSDed, whatever. However, it is essentially open, except for commercial use. You get source if you want it, you can modify it. I'd never actually seen the UC license, so I decided to see what the actual COPYING file that comes with the tarball says. Here is is:

    Copyright 2002 The Regents of the University of California All Rights Reserved

    Permission to use, copy, modify and distribute any part of this SDSC-syslog program for educational, research and non-profit purposes, without fee, and without a written agreement is hereby granted, provided that the above copyright notice, this paragraph and the following paragraphs appear in all copies.

    Those desiring to incorporate this SDSC-syslog program into commercial products or use for commercial purposes should contact the Technology Transfer Office, University of California, San Diego, 9500 Gilman Drive, La Jolla, CA 92093-0910, Ph: (619) 534-5815, FAX: (619) 534-7345.

    IN NO EVENT SHALL THE UNIVERSITY OF CALIFORNIA BE LIABLE TO ANY PARTY FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, INCLUDING LOST PROFITS, ARISING OUT OF THE USE OF THIS SDSC-syslog PROGRAM, EVEN IF THE UNIVERSITY OF CALIFORNIA HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

    THE SDSC-syslog SOFTWARE PROVIDED HEREIN IS ON AN "AS IS" BASIS, AND THE UNIVERSITY OF CALIFORNIA HAS NO OBLIGATION TO PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS. THE UNIVERSITY OF CALIFORNIA MAKES NO REPRESENTATIONS AND EXTENDS NO WARRANTIES OF ANY KIND, EITHER IMPLIED OR EXPRESS, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, OR THAT THE USE OF THE SDSC-syslog SOFTWARE WILL NOT INFRINGE ANY PATENT, TRADEMARK OR OTHER RIGHTS.

    SDSC-syslog is developed by Tom Perrine at San Diego Supercomputer Center at the University of California, San Diego. Support for this effort is provided by Commerce Net (CN-NGI01-009).

    After some not-so-trivial digging, I found the UC guidelines for releasing software [ucop.edu]. Essentially, any software written by a UC employee can be made "public" as long as procedures are followed and it's released for non-commercial use (with a license statement accompanying the software stating such).

    Bash away at the software's non-GPLness, but I for one think it's pretty spiffy that anything a UC faculty, student of staff member writes can be given away, in source form, to the public. Anyone who works in the private sector who is allowed give away software written on the corporate dime can either speak up or hush up.

    Anyway, cut 'em a little slack, would ya? They're trying.

    -B

    • I work with folks at UC on the Cheshire Project which also uses this licence. We'd like to be able to use the GPL, but this is sure better than nothing , so I agree with the parent poster

      http://cheshire.berkeley.edu/ [berkeley.edu]

      -- Azaroth
  • Anybody have any more info about if and when the license might change?
  • Metalog [sourceforge.net] works pretty good for me, YMMV, but I have been using it for more than 6 months. AFAIK, the current metalog does not support remote logging, however, it is planned to be added in the future. A quote from their site regarding its capabilities:

    Metalog is a modern replacement for syslogd and klogd. The logged messages can be dispatched according to their facility, urgency, program name and/or Perl-compatible regular expressions.
    Log files can be automatically rotated when they exceed a certain size or age.
    External shell scripts (ex: mail) can be launched when specific patterns are found.

    Metalog is easier to configure than syslogd and syslog-ng, accepts unlimited number of rules and has (switchable) memory bufferisation for maximal performance.

  • An interesting extension of a lousy idea. (Score:4, Interesting)

    by Doktor Memory ( 237313 ) on Thursday December 05, 2002 @03:07PM (#4820177) Journal
    Although it's nice to see people attempting to improve one of the more regularly broken unix core services, I still think that the whole syslog design of a monolithic central multiplexed logging daemon is the Wrong Design.

    Dan Bernstein's multilog, from his daemontools [cr.yp.to] package, is, in my opinion, a good example of the correct way to do logging: a single process logs the stdout and stderr of each daemon, goes to great lengths to ensure that no data is lost, and handles logfile rollover automatically. With this tcpserver/tcpclient utilities from his ucspi-tcp [cr.yp.to] package, it can be simply done over a network as well.

    Of course, DJB's code, while source-available, is not in any way Free Software, and daemontools in particular currently is inextricably linked into his extraordinarily dubious "slashpackage" system, making it a potentially annoying choice for anyone reselling or distributing systems based on it. Cronolog [cronolog.org], which was originally created to manage apache logs, looks like a promising GPLed replacement for multilog, but despite lots of grumbling along those lines, nobody has written a gpl/bsd replacement for daemontools...yet.
  • It's very funny, only yesterday i published on a mailing list my proposal for a new syslog daemon architecture:

    Syslog Daemon Architecture [myip.org]

    I wrote this document for the msyslog [sourceforge.net] project.

    And then, today, i noticed the sdscsyslog announcement on Slashdot! :-)

    There are many similarities between their architecture and my proposal:
    - modularity
    - extensibility
    - scalability, etc.
    • This is again another problem with open source projects. Lack coordination amoungst projects. How many sub-systems does it take to do the same unit of work?

      We have syslog, syslog-ng, a proposal for msyslog, this new version from the university system.

      All this does is prove to the M$ marketing machines that opensource has no teeth, let alone coordinated ability to ensure redundant work does not happen.

      So where's the compare/contrast to all that came before that convinces people any one of the proposed solutoin is the superior to the previous and its time to move up the IT evolutionary chain.

      If we used the same efforts used in open source to supply gas stations there would exist 100+ recipies for grades of fuel and a creeky still & cracking tower would have to be setup next to the gas pump. Until someone took upon the entrepreneurial challenge it wouldn't come out of the spout for consumers. -- until then it would remain something you would have to assemble yourself.

      Yet another example of cowboy IT development shooting its own industry in the foot.
      • Well, not exactly.
        The traditional syslog is old, broken and dying. It doesn't count.
        syslog-ng is cute and has TCP and clever message filtering. But that's all.
        msyslog goes beyond that and adds true and reliable SQL logging (SQL in syslog-ng is a joke), PEO message protection (tamper-evident) and a somewhat more extensible implementation. But it stops there.
        sdscsyslog is the first attempt to solve all the problems with all the other implementations, and also adds long-awaited features. However, it does not overlap with my proposal, because mine is just... heh, just a proposal, while they already have a running application.

        But i agree with you. There is some fragmentation in the Open Source / Free Software world.
  • sdscsyslogd-1.0.0 RC4 does not compile on Solaris 8, nor on FreeBSD.

    The 'configure' script does not report any problems, and correctly detects the operating system. FreeBSD has some problems with the 'sed' substitutions for "include/const.h".

    Using GCC on either platform, the compile pukes in "src/util/netaddr.h". It appears that SDSC syslogd can only successfully compile on Linux, due to use of Linux-specific socket structure declarations in this file?

    gcc -DHAVE_CONFIG_H -I. -I. -I../../src/include -I../../src -g -Wall -Wno-inl
    ine -Wstrict-prototypes -O2 -pedantic -c `test -f config.c || echo './'`config.
    c
    In file included from ../../src/message/message.h:25,
    from ../../src/outputmod/outputmod.h:23,
    from ../../src/include/chaninfo.h:23,
    from config.c:19:
    ../../src/util/netaddr.h:98: field `sa' has incomplete type
    ../../src/util/netaddr.h:99: warning: ISO C doesn't support unnamed structs/unio
    ns
    ../../src/util/netaddr.h:99: warning: no semicolon at end of struct or union
    ../../src/util/netaddr.h:99: parse error before numeric constant
    ../../src/util/netaddr.h:100: warning: built-in function `sin' declared as non-f
    unction
    ../../src/util/netaddr.h:102: parse error before '}' token
    ../../src/util/netaddr.h:102: warning: ISO C does not allow extra `;' outside of
    a function
    In file included from ../../src/include/chaninfo.h:23,
    from config.c:19:
    ../../src/outputmod/outputmod.h:75: field `sendTo' has incomplete type
    ../../src/outputmod/outputmod.h:82: confused by earlier errors, bailing out

  • Just look at the code. It's all "check that we have enough size", "copy that much data there", etc. It's all too easy to make mistakes with that. I found two missing checks, non-exploitable though. Also I found another almost-exploitable overflow with it's IPC, it used malloc(len) instead malloc(len*4). Only reason it's not exploitable is that the length was always either 0 or 1.

    vsftpd handles buffers the right way - quoting security/implementation doc:

    The problem is that people insist on replicating buffer size handling code and buffer size security checks many times (or, of course, they omit size checks altogther). It is little surprise, then, that sometimes errors creep in to the checks.

    The correct solution is to hide the buffer handling code behind an API. All buffer allocating, copying, size calculations, extending, etc. are done by a single piece of generic code. The size security checks need to be written once. You can concentrate on getting this one instance of code correct.

    • very good point! (Score:4, Informative)

      by halfelven ( 207781 ) on Thursday December 05, 2002 @06:50PM (#4822058)

      I think many people could do themselves a great service by simply studying the vsftpd security libraries. Those are generic enough to be used by almost any other application, and provide a solid foundation to write applications that do not fall apart under classic C exploits: buffer overflows, etc.

      Check here the vsftpd website [beasts.org].

  • A time for ipsec? (Score:2, Interesting)

    by Anonymous Coward
    do we really need specialized encryption built into each application? why not just use something at the stack level?
  • ....syslog-ng, also verify non-spoofed ip address and there it is, almost perfect (if your front server is compromised though, your syslog can still be DOS's, though not poisonable (no rewind there)...
  • For the license [sdsc.edu].
    If this product were to be released under a Free-software license I'd definately consider it on our network. As it is I (and probably many others) will use something else like syslong-ng or metalog, despite the fact that SDSC-syslog seems to be far more technically competent.
  • As usual, this being a 1.3.x release, I haven't even compiled this
    kernel yet. So if it works, you should be doubly impressed.
    -- Linus Torvalds, announcing kernel 1.3.3

    - this post brought to you by the Automated Last Post Generator...

Slashdot Top Deals

I tell them to turn to the study of mathematics, for it is only there that they might escape the lusts of the flesh. -- Thomas Mann, "The Magic Mountain"

Close