Re: ELOG security vulnerability fixed, IMPORTANT!!!!, posted by Recai Oktas on Mon Feb 14 18:49:44 2005
|
Attention to Debian users;
I've prepared the fixed package and also contacted to Debian Security Team for
an urgent security upload. Since then you may wish to update your package from
the following URL:
http://l10n-turkish.alioth.debian.org/debian/elog_2.5.7+r1558-1_i386.deb
Or you can also make an update via apt-get by adding the below line to your
'/etc/apt/sources.list' file:
deb http://l10n-turkish.alioth.debian.org/debian/ ./
> The second vulnerability had to do with write passwords. If you put a "write
> password = xxx" statement into your config file, it was still possible to
> download the config file with a special hand-written URL, and decode the
> write password, which is usually only base-64 encoded unless you haven't
> compiled elog with the -DHAVE_CRYPT flag.
FYI, Debian package has already been compiled with this flag.
-- Recai Oktas, Maintainer of Debian package |
|
ELOG security vulnerability fixed, IMPORTANT!!!!, posted by Stefan Ritt on Mon Feb 14 12:36:30 2005
|
Dear ELOG users,
It has been brought to my attention that ELOG has a vulnerability through
which one can obtain a remote shell (meaning to log in to your machine
through elog). There is even an exploit available which demonstrates that
both for linux and windows.
This is a severe security problem for all logooks which can be seen from
outside, even if they have password protection on. I strongly recommened to
upgrade to elog version 2.5.7 as soon as possible if you run a public elog
server.
Here is some explanation for the technically interested:
The problem arises from a strcpy() in the decode_post() routine, which
triggers a buffer overflow when attachment file names longer than 256
characters are submitted. I replaced (hopefully) all strcpy() with strlcpy()
to fix this problem, but if someone sees a location which I have missed,
please tell me.
The second vulnerability had to do with write passwords. If you put a "write
password = xxx" statement into your config file, it was still possible to
download the config file with a special hand-written URL, and decode the
write password, which is usually only base-64 encoded unless you haven't
compiled elog with the -DHAVE_CRYPT flag. I have changed that so if a write
password is present, the download is only possible when this password is
submitted in each request. If this has some effects on synchronizing of
logbooks, please let me know.
Stefan Ritt |
Re: Find using multiple values with MOptions, posted by Stefan Ritt on Fri Jan 21 23:30:35 2005
|
<SELECT NAME="lid" multiple size="5">
Oh, nice, I didn't know of that. However, I prefer to have multiple options to be selected
with individual check boxes, this saves more vertical window space. So I added that
functionality to the find page. If more than one option of a MOptions attribute are
selected, they are or'ed together during the search. You can try that in this forum with
the "OS" for example. |
Re: Find using multiple values with MOptions, posted by Neil Swartz on Wed Jan 19 04:33:00 2005
|
> > Currently there is a dropdown when searching for MOption fields. Maybe you could
> > allow multiple selections in the dropdown. This to me is an "OR" search.
>
> Multiple selections are not possible in HTML, only a single value can be selected at
> a time.
Try: (From monster.com)
<SELECT NAME="lid" multiple size="5">
<OPTION VALUE=""> ------- Select all -------- </OPTION>
<OPTION VALUE="323">Alabama-Anniston</OPTION>
<OPTION VALUE="324">Alabama-Birmingham</OPTION>
<OPTION VALUE="325">Alabama-Mobile/Dothan</OPTION>
<OPTION VALUE="328">Alabama-Montgomery</OPTION>
...
</SELECT>
Although this may not be supported in all browsers. (I think recent versions of
Netscape and IE support it) |
|
Re: external authentication possible?, posted by Stefan Ritt on Sun Dec 12 12:49:06 2004
|
> The only common denominator that could possibly cover all contingencies would
> be LDAP authentication. One way of doing this in a more-or-less universal
> fashion is to offload the auth task from eLog itself and place the burden on
> Apache. This means figuring out how to get Apache to pass auth info to eLog
> when eLog operates behind Apache. In the end, anything that can use LDAP as an
> authentication mechanism (like AD) can host eLog - as long as eLog can glom off
> of Apache's ability to do the actual authenticating.
That sounds to me like a great idea. If anybody gets this working, people would be
grateful if this could be submitted to the "Contributions" section of this forum. |
Re: external authentication possible?, posted by Steve Allen on Tue Dec 7 01:18:14 2004
|
> > > In order to avoid having to remember multiple usernames/passwords for
> > > different systems, is it possible for ELOG to use external authentication
> > > via Active Directory, etc?
> >
> > Not yet.
>
> I would note that this is a request that comes in fairly frequently, but to
> Stephan's credit (and looking back at previous comments) the task of trying to
> implement authentication that would *not* be a maintenance nightmare basically
> pushes such a request down to the bottom of the list.
>
> The only common denominator that could possibly cover all contingencies would
> be LDAP authentication. One way of doing this in a more-or-less universal
> fashion is to offload the auth task from eLog itself and place the burden on
> Apache. This means figuring out how to get Apache to pass auth info to eLog
> when eLog operates behind Apache. In the end, anything that can use LDAP as an
> authentication mechanism (like AD) can host eLog - as long as eLog can glom off
> of Apache's ability to do the actual authenticating.
>
> For our twiki (source from twiki.org) website, we use the following config:
>
> -- In Apache http.conf
> LoadModule auth_ldap_module libexec/auth_ldap.so
>
> AddModule auth_ldap.c
>
> AccessFileName .htaccess
>
> # Twiki
> Include /proj/www/twiki/conf/httpd.conf
>
>
> -- The http.conf in the Twiki directory
> <VirtualHost *>
> DocumentRoot "/proj/www/twiki/html"
> ServerName twiki
> ErrorLog error_log
> CustomLog access_log combined
> <Directory "/proj/www/twiki/html/bin/">
> Options +ExecCGI
> allow from all
> AllowOverride Authconfig FileInfo Indexes Limit Options
> </Directory>
> <Location /bin>
> Options +ExecCGI
> AuthType Basic
> AuthName CoreID
> CustomLog access_log combined
> <Directory "/proj/www/twiki/html/bin/">
> Options +ExecCGI
> allow from all
> AllowOverride Authconfig FileInfo Indexes Limit Options
> </Directory>
> <Location /bin>
> Options +ExecCGI
> AuthType Basic
> AuthName ID
> AuthLDAPURL
> ldap://ldap.co.com:389/ou=People,ou=Intranet,dc=co,dc=com?uid?sub?(objectClass=*)
> require valid-user
> allow from all
> <Limit OPTIONS>
> Order Deny,Allow
> Deny from all
> </LIMIT>
> </Location>
> </VirtualHost>
>
> --- Then the DocumentRoot ("/proj/www/twiki/html") has a '.htaccess' file with
> the following:
>
> RedirectPermenant / http://twiki.co.com/bin/view.cgi
>
> --- Also in the /bin directory we have:
>
> Redirect http://twiki.sps.mot.com/index.html http://twiki.sps.mot.com/bin/view.cgi
>
> AuthType Basic
> AuthName "LDAP Login"
> AuthLDAPURL
> ldap://ldap.co.com:389/ou=People,ou=Intranet,dc=co,dc=com?uid?sub?(objectClass=*)
>
>
> SetHandler cgi-script
>
> ErrorDocument 401 /bin/oops.cgi/TWiki/TWikiRegistration?template=oopsauth
>
> <Files ~ "[^/]*\.html$">
> SetHandler blabla
> allow from all
> </Files>
>
> <Files "*">
> require valid-user
> allow from all
> </Files>
> -------------------------
>
> Whether this is at all relevant, well . . . .
Food for thought--thanks! |
|
Re: external authentication possible?, posted by Steve Jones on Mon Dec 6 22:48:19 2004
|
> > In order to avoid having to remember multiple usernames/passwords for
> > different systems, is it possible for ELOG to use external authentication
> > via Active Directory, etc?
>
> Not yet.
I would note that this is a request that comes in fairly frequently, but to
Stephan's credit (and looking back at previous comments) the task of trying to
implement authentication that would *not* be a maintenance nightmare basically
pushes such a request down to the bottom of the list.
The only common denominator that could possibly cover all contingencies would
be LDAP authentication. One way of doing this in a more-or-less universal
fashion is to offload the auth task from eLog itself and place the burden on
Apache. This means figuring out how to get Apache to pass auth info to eLog
when eLog operates behind Apache. In the end, anything that can use LDAP as an
authentication mechanism (like AD) can host eLog - as long as eLog can glom off
of Apache's ability to do the actual authenticating.
For our twiki (source from twiki.org) website, we use the following config:
-- In Apache http.conf
LoadModule auth_ldap_module libexec/auth_ldap.so
AddModule auth_ldap.c
AccessFileName .htaccess
# Twiki
Include /proj/www/twiki/conf/httpd.conf
-- The http.conf in the Twiki directory
<VirtualHost *>
DocumentRoot "/proj/www/twiki/html"
ServerName twiki
ErrorLog error_log
CustomLog access_log combined
<Directory "/proj/www/twiki/html/bin/">
Options +ExecCGI
allow from all
AllowOverride Authconfig FileInfo Indexes Limit Options
</Directory>
<Location /bin>
Options +ExecCGI
AuthType Basic
AuthName CoreID
CustomLog access_log combined
<Directory "/proj/www/twiki/html/bin/">
Options +ExecCGI
allow from all
AllowOverride Authconfig FileInfo Indexes Limit Options
</Directory>
<Location /bin>
Options +ExecCGI
AuthType Basic
AuthName ID
AuthLDAPURL
ldap://ldap.co.com:389/ou=People,ou=Intranet,dc=co,dc=com?uid?sub?(objectClass=*)
require valid-user
allow from all
<Limit OPTIONS>
Order Deny,Allow
Deny from all
</LIMIT>
</Location>
</VirtualHost>
--- Then the DocumentRoot ("/proj/www/twiki/html") has a '.htaccess' file with
the following:
RedirectPermenant / http://twiki.co.com/bin/view.cgi
--- Also in the /bin directory we have:
Redirect http://twiki.sps.mot.com/index.html http://twiki.sps.mot.com/bin/view.cgi
AuthType Basic
AuthName "LDAP Login"
AuthLDAPURL
ldap://ldap.co.com:389/ou=People,ou=Intranet,dc=co,dc=com?uid?sub?(objectClass=*)
SetHandler cgi-script
ErrorDocument 401 /bin/oops.cgi/TWiki/TWikiRegistration?template=oopsauth
<Files ~ "[^/]*\.html$">
SetHandler blabla
allow from all
</Files>
<Files "*">
require valid-user
allow from all
</Files>
-------------------------
Whether this is at all relevant, well . . . . |
|
Re: New ELOG version with XML and CSV import/export, posted by Stefan Ritt on Wed Nov 24 11:45:07 2004
|
> BTW,
> Is there any way to turn off the Text column at the right side of the list?
Summary lines = 0 |
|