lota / phamm Goto Github PK

Hi, there is a limit of 15 chars on the Password field, that can be confusing.
If the user generates a password with more than 15 chars, and copy them into the password field, the password is cutting to a length of 15 chars. So if the user try to login with his own password the passwords will never match.
Is there a special reason with LDAP thats need a max length of 15 chars?

ldap_sort() is deprecated.

Dear team,
I have installed phamm 0.6.5 and ldap on Ubuntu 14.04 machine but I can't create a new domain after I log in as admin. I got error log in apache2 as below :

[Mon May 16 11:18:52.067787 2016] [:error] [pid 22472] [client 172.16.10.1:54081] PHP Warning: ldap_add(): Add: Invalid DN syntax in /var/www/html/phamm/lib/ldap.php on line 119, referer: http://172.16.10.12/phamm/public/main.php
[Mon May 16 11:18:52.068535 2016] [:error] [pid 22472] [client 172.16.10.1:54081] PHP Warning: ldap_add(): Add: Invalid DN syntax in /var/www/html/phamm/lib/ldap.php on line 119, referer: http://172.16.10.12/phamm/public/main.php
[Mon May 16 11:18:52.069057 2016] [:error] [pid 22472] [client 172.16.10.1:54081] PHP Warning: ldap_add(): Add: Invalid DN syntax in /var/www/html/phamm/lib/ldap.php on line 119, referer: http://172.16.10.12/phamm/public/main.php

I have configured ldap as example instruction.

Reflected Cross Site Scripting
Issue :
Cross-Site Scripting (XSS) attack is a type of injection attack, in which malicious code is injected into trusted web sites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side code, to a different end user. The end user’s browser has no way to know that the code should not be trusted, and will execute the code. Because the end user thinks the script came from a trusted source, the malicious code can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site. This code can even rewrite the content of the HTML page.

Proof Of Concept :
URL : http://localhost/phamm/public/main.php?action=%3C/title%3E%3Cbody%20onload=alert(1)%3E%3C/body%3E

Reason for this issue is $action is not sanitised and is reflected inside the title.

In public/main.php, inetLocalMailRecipient is used when creating a new domain:

inetLocalMailRecipient seems to come from misc.schema, but misc.schema conflicts with ISPEnv2.schema. Is there something I'm missing here?

I am getting an object not found when trying to create a new domain. If I comment that line out in main.php, the domain gets added without issue. If I try to add misc, then I get errors trying to include ISPEnv2.

Should the inetLocalMailRecipient be there at all? I notice that in the example mail.ldif the domain object does not use it.

I am not very proficient with LDAP in general so I am not sure if I am missing something. Sorry if this is a silly question.

Time: 30.07.2015 12:45:07
Error: TypeError: f is null
Source: http://demo.phamm.org/phamm/functions.js
Line: 35

phamm Version: 0.6.2

The Javascript should be fired after the page is completly loaded.
If you don't like Jquery you can do this by the oldscool :

Or you use another crossbrowser solution, but i guess jquery can be a good basic for all your frontend issues

In handle_vacation.sh, I've found that ldapsearch will often generate new-lines when writing to TMPFILE if the DN is "too" long. I suggest/recommend adding "-o ldif-wrap=no" to the ldapsearch command which resolves the problem.

using php8.2
PHP Fatal error: Uncaught Error: Call to undefined function ldap_sort() in lib/ldap.php

I noticed that the check on maximum allowed account is only on the level of the web interface: only when on the web interface is pushed the button "Add new account" the code checks whether the number of allowed alias is overtaken and if it is, then the mask for adding new alias is blocked.

I think that this is not enough because the user can pass this type of control simply by manually pushing a custom http POST request with the required data. To be safe the control on the maximum number of alias should be performed whenever there is a ldap_add query from any legitimated user (inside of the case "insert_account" clause)!
$r = PhammLdap::phamm_add ('mail='.$mail.',vd='.$domain.','.LDAP_BASE,$entry);

The following shell example works for whichever maxAlias is set (only the cookies line needs to be change accordlying to a valid user session):
$ wget --post-data "action=insert_account&account_new=useralias%40examplet.tld&password1=ccc&password2=ccc&givenname=cc&sn=cc&confirm%5B%5D=alias&values_multi%5Balias%5D%5Bmaildrop%5D=admin&values%5Balias%5D%5Baccountactive%5D=TRUE&values%5Balias%5D%5Bsmtpauth%5D=FALSE&values%5Balias%5D%5Bamavisbypassviruschecks%5D=TRUE&values%5Balias%5D%5Bamavisbypassspamchecks%5D=TRUE&values%5Bproxy%5D%5Bwebaccess%5D=TRUE&values%5Bproxy%5D%5Bproxyhost%5D=&values%5Bperson%5D%5Btelephonenumber%5D=&values%5Bperson%5D%5Bhomephone%5D=&values%5Bperson%5D%5Bmobile%5D=&values%5Bperson%5D%5Bfacsimiletelephonenumber%5D=&values%5Bperson%5D%5Bpager%5D=&values%5Bdavical%5D%5Bcaldavaccess%5D=TRUE" --header "Cookie: PHPSESSID=a0lfboqfpjn5hr68uabt8mur35; 5d89dac18813e15aa2f75788275e3588=ef6nq8oda14rdt3pa8bhgv6h77; collapsedNodes=" --header "Location: http://127.0.0.1/phamm/main.php?action=domain_view&domain=examplet.tld" http://127.0.0.1/phamm/main.php

--- More datails ---
Using phamm version:

$ apt-cache policy phamm
phamm:
  Installed: 0.6.2-1.2
  Candidate: 0.6.2-1.2
  Version table:
 *** 0.6.2-1.2 0
        500 http://http.debian.net/debian/ jessie/main amd64 Packages

It's a part of my phamm.acl:

access to dn.regex=".+,vd=([^,]+),ou=hosting,dc=tronet,dc=ru$" attrs=userPassword
by dn="cn=admin,dc=tronet,dc=ru" write
by self write
by anonymous auth
by dn.exact,expand="cn=postmaster,vd=$1,ou=hosting,dc=tronet,dc=ru" write
by set.expand="user/vd & [$1]" write

access to dn.regex=".+,vd=([^,]+),ou=hosting,dc=tronet,dc=ru$" attrs=amavisBypassVirusChecks,quota,smtpAuth,accountActive
by dn="cn=admin,dc=tronet,dc=ru" write
by self read
by dn.exact="cn=phamm,ou=hosting,dc=tronet,dc=ru" read
by set.expand="user/editAccounts & [TRUE]" write
by dn.exact,expand="cn=postmaster,vd=$1,ou=hosting,dc=tronet,dc=ru" read
by set.expand="user/vd & [$1]" write

access to dn.regex=".+,vd=([^,]+),ou=hosting,dc=tronet,dc=ru$" attrs=cn,sn,uid,forwardActive,vacationActive,vacationInfo,vacationStart,vacationEnd,vacationForward,amavisSpamTag
Level,amavisSpamTag2Level,amavisSpamKillLevel
by dn="cn=admin,dc=tronet,dc=ru" write
by self write
by dn.exact="cn=phamm,ou=hosting,dc=tronet,dc=ru" read
by dn.exact,expand="cn=postmaster,vd=$1,ou=hosting,dc=tronet,dc=ru" write
by set.expand="user/vd & [$1]" write

access to dn.regex="^.*,vd=([^,]+),ou=hosting,dc=tronet,dc=ru$" attrs=editAccounts
by dn="cn=admin,dc=tronet,dc=ru" write
by self read
by set.expand="user/editAccounts & [TRUE]" write
by dn.exact="cn=phamm,ou=hosting,dc=tronet,dc=ru" read
by * none

access to dn.regex=".+,vd=([^,]+),ou=hosting,dc=tronet,dc=ru$" attrs=objectClass,entry
by dn="cn=admin,dc=tronet,dc=ru" write
by self write
by anonymous read
by dn.exact="cn=phamm,ou=hosting,dc=tronet,dc=ru" read
by set.expand="user/editAccounts & [TRUE]" write
by dn.exact,expand="cn=postmaster,vd=$1,ou=hosting,dc=tronet,dc=ru" read

access to dn.regex=".+,vd=([^,]+),ou=hosting,dc=tronet,dc=ru$" attrs=amavisBypassSpamChecks,accountActive,delete
by dn="cn=admin,dc=tronet,dc=ru" write
by self read
by dn.exact="cn=phamm,ou=hosting,dc=tronet,dc=ru" read
by dn.exact,expand="cn=postmaster,vd=$1,ou=hosting,dc=tronet,dc=ru" write
by set.expand="user/vd & [$1]" write

access to dn.regex=".+,vd=([^,]+),ou=hosting,dc=tronet,dc=ru$" attrs=otherPath
by dn="cn=admin,dc=tronet,dc=ru" write
by anonymous read
by self read
by dn.exact="cn=phamm,ou=hosting,dc=tronet,dc=ru" read
by dn.exact,expand="cn=postmaster,vd=$1,ou=hosting,dc=tronet,dc=ru" read
by set.expand="user/vd & [$1]" write

When i try modify mail account by postmaster, en erro occured:

Mar 3 09:34:46 ldap slapd[78222]: conn=1020 op=0 BIND dn="cn=postmaster,vd=comberg.ru,ou=hosting,dc=tronet,dc=ru" method=128
Mar 3 09:34:46 ldap slapd[78222]: conn=1020 op=0 BIND dn="cn=postmaster,vd=comberg.ru,ou=hosting,dc=tronet,dc=ru" mech=SIMPLE ssf=0
Mar 3 09:34:46 ldap slapd[78222]: conn=1020 op=0 RESULT tag=97 err=0 text=
Mar 3 09:34:46 ldap slapd[78222]: conn=1020 op=1 SRCH base="vd=comberg.ru,ou=hosting,dc=tronet,dc=ru" scope=2 deref=0 filter="(vd=comberg.ru)"
Mar 3 09:34:46 ldap slapd[78222]: <= mdb_equality_candidates: (vd) not indexed
Mar 3 09:34:46 ldap slapd[78222]: conn=1020 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=
Mar 3 09:34:46 ldap slapd[78222]: conn=1020 op=2 SRCH base="vd=comberg.ru,ou=hosting,dc=tronet,dc=ru" scope=2 deref=0 filter="(&(objectClass=VirtualMailAccount)(!(cn=postmaster))(!(mail=abuse@*)))"
Mar 3 09:34:46 ldap slapd[78222]: conn=1020 op=2 SEARCH RESULT tag=101 err=0 nentries=4 text=
Mar 3 09:34:46 ldap slapd[78222]: conn=1020 op=3 MOD dn="mail=[email protected],vd=comberg.ru,ou=hosting,dc=tronet,dc=ru"
Mar 3 09:34:46 ldap slapd[78222]: conn=1020 op=3 MOD attr=sn givenname cn smtpauth quota accountactive vdhome mailbox uid mailautoreply delete othertransport vacationactive vacationstart vacationend forwardactive amavisbypassviruschecks amavisbypassspamchecks amavisspamkilllevel amavisspamtag2level amavisspamtaglevel creationdate lastChange userPassword
Mar 3 09:34:46 ldap slapd[78222]: conn=1020 op=3 RESULT tag=103 err=50 text=
Mar 3 09:34:46 ldap slapd[78222]: conn=1020 op=4 UNBIND
Mar 3 09:34:46 ldap slapd[78222]: conn=1020 fd=20 closed

https://bugs.launchpad.net/ubuntu/+source/phamm/+bug/1570968

If i chang the Language Select, nothing is happen.
So i test it again with your Demo, but the behavior is the same, after changing the language selector, nothing is happen.

Tips and hints are welcome

While looking through codesearch.debian.net I noticed that phamm's views/helpers.php uses $_SERVER['PHP_SELF'] in a way that is vulnerable to reflected XSS attacks.

To reproduce the problem, load a URL like this in Firefox:

http://127.0.0.1/phamm/main.php/%22%3E%3Cscript%3Ealert%28123%29%3C/script%3E

The Debian Security team assigned this issue CVE-2017-0378

What about the possibility to force new passwords to contain special character,
uppercase letters or numbers?

Andrea

The files views/helpers.php:699 and view/helper.php:678 create the input type for inserting the password with the attributes size="15" maxlength="15".

Problem arises when a user inserts a password longer than that: it is silently truncate and then updated without any warning.

I would suggest to add the following implementations:

• create a warning if the password is longer than that;
• add a field in pham config for setting longer passwords;

What do you think about?

addendum: I notice that no more dots are added when the limit of 15 chars is reached, but I thing that is not really easy to be noticed by the users.