The below was published on mod_survey's mailing list a few minutes ago. More info about Mod_Survey can be found on its home page, which is available at http://gathering.itm.mh.se/modsurvey/ // Joel ###################################################### Mod_Survey Security Advisory 2003-05-04, SYSBASE flood ###################################################### ABOUT MOD_SURVEY ---------------- Mod_Survey is an Apache module which displays and handles questionnaires written in a special XML-based markup language. Mod_Survey is primarily targeted towards Linux/Unix, but is also possible to run in Windows. SUMMARY ------- In all versions prior to 3.0.15-stable, it is possible for a remote evil person to fill the partition on which the central data repository resides, through sending access requests to non-existing surveys. ERROR CATEGORY -------------- The error falls into the classes "Input Validation Error" and "Denial of Service". It is possible to exploit remotely. VULNERABLE ---------- All versions from 3.0.0 up to (but not including) 3.0.15-stable are vulnerable. Thus the following versions have the problem: 3.0.0 3.0.1 3.0.2 3.0.3 3.0.4 3.0.5 3.0.6 3.0.7 3.0.8 3.0.9 3.0.10 3.0.11 3.0.12 3.0.13 3.0.14 3.0.14d 3.0.14e 3.0.15-pre1 3.0.15-pre2 3.0.15-pre3 3.0.15-pre4 3.0.15-pre5 3.0.15-pre6 Not vulnerable: 3.0.15-stable SOLUTION -------- All users are encouraged to upgrade to version 3.0.15-stable. However, if you are running 3.0.14 - 3.0.14e and do not wish to upgrade at this time, you could also download the "Document.pm" module from the mod_survey homepage (http://gathering.itm.mh.se/modsurvey/) and use it to replace the faulty one in the "Survey" subdir of the installation folder. This is not an option if you run versions prior to 3.0.14. Apache needs to be stopped (to a full stop, not "graceful") and then started again before changes in these modules take effect. LONGER DISCUSSION ----------------- Mod_survey does per default store all data files, such as cache, keys and submitted questionnaire answers, in a data repository, "SYSBASE". In practise this repository is a subdir of the central data repository. SYSBASE is created when the survey file is first accessed, and is given the full path of the survey as name (with slashes converted to underscores). Unfortunately, the check whether the survey file actually exists did not take place until *after* the repository was initialized. Thus, an empty SYSBASE would be set up even if the access concerned a non-existent survey file. In normal operation, this might look rather sloppy, but would not a be problem, since the occasional mistyped path would only result in an additional empty directory. However, while the directory is "empty" in the sense that it does not contain any data from the beginning, it still occupies space in the file system. A script with a loop that produces access requests to new non-existent surveys several times per second would pretty soon fill the partition. The consequences of this differ depending on which platform the system is installed, and which partition contains the data repository. The usual consequence would simply be that no data could be written to the partition, thus stopping further data collection. However, in theory, a filled partition could down a system. An example would be on a unixoid system where the data repository resided somewhere in /var (the default location is in /usr/local/mod_survey/data). EXPLOIT ------- An exploit exists and is shown to be functional, but has to our knowledge not reached the public. However, given the nature of the problem, anyone with a minimum of knowledge of any scripting language could easily reproduce the exploit from the above information. IMPACT ------ All current installations of mod_survey are vulnerable and could thus at least be attacked with a DoS attack exploiting the above. It is conceivable that the problem could also be used to attack bugs in the file system itself, as an example through injecting control chars that the operating system cannot handle, although no exploit for this has yet been proposed. An upgrade to 3.0.15-stable removes the theoretical possibility for this problem too though. CREDITS ------- The problem was first discovered and discussed by Jesse Adelman of the University of California, San Francisco.
This archive was generated by hypermail 2b30 : Mon May 05 2003 - 08:09:29 PDT