philippj / yubico-yubiserve

Automatically exported from code.google.com/p/yubico-yubiserve

Hi there 👋

yubico-yubiserve's Issues

Does not reconnect to mysql after session killed

The code does not attempt to reconnect to MySQL when a session is killed.

This occurs naturally when MySQL kills idle connections, depending on what 
"wait_timeout" is set to
in MySQL.  This by default is 28800 seconds (8 hours).

The issue can be replicated easily by closing the connection used from MySQL.  
After closing the connection, curl
gets "Empty reply from server" as it's outout.

1. Start yubserve, connected to MySQL.

2. In MySQL show the processes, and kill the connection.

mysql> show full processlist \g;
+-----+-------------+-----------+-----------+---------+--------+----------------
-------------------------------------------------------+-----------------------+
| Id  | User        | Host      | db        | Command | Time   | State          
                                                       | Info                  |
+-----+-------------+-----------+-----------+---------+--------+----------------
-------------------------------------------------------+-----------------------+
|   1 | system user |           | NULL      | Connect | 220399 | Has read all 
relay log; waiting for the slave I/O thread to update it | NULL                 
 |
|   2 | system user |           | NULL      | Connect | 220399 | Connecting to 
master                                                  | NULL                  
|
| 266 | yubiserve   | localhost | yubiserve | Sleep   |    385 |                
                                                       | NULL                  |
| 271 | root        | localhost | NULL      | Query   |      0 | NULL           
                                                       | show full processlist |
+-----+-------------+-----------+-----------+---------+--------+----------------
-------------------------------------------------------+-----------------------+
4 rows in set (0.00 sec)

mysql> kill connection 266;
Query OK, 0 rows affected (0.00 sec)

mysql> show full processlist \g;
+-----+-------------+-----------+------+---------+--------+---------------------
--------------------------------------------------+-----------------------+
| Id  | User        | Host      | db   | Command | Time   | State               
                                                  | Info                  |
+-----+-------------+-----------+------+---------+--------+---------------------
--------------------------------------------------+-----------------------+
|   1 | system user |           | NULL | Connect | 220437 | Has read all relay 
log; waiting for the slave I/O thread to update it | NULL                  |
|   2 | system user |           | NULL | Connect | 220437 | Connecting to 
master                                                  | NULL                  
|
| 272 | root        | localhost | NULL | Query   |      0 | NULL                
                                                  | show full processlist |
+-----+-------------+-----------+------+---------+--------+---------------------
--------------------------------------------------+-----------------------+
3 rows in set (0.00 sec)

3. Try a sample query:

11:08:29 [root@OpenGW1 yubiserve]$ curl 
'http://localhost:8000/wsapi/2.0/oathverify?otp=458463&publicid=testtesttest'
curl: (52) Empty reply from server

Original issue reported on code.google.com by [email protected] on 19 Dec 2012 at 10:15

Different version numbers (3.0 vs. 3.1)

What steps will reproduce the problem?
1. Look at the version number of README.
2. Look at the version number of yubiserve.py

What is the expected output? What do you see instead?
Both numbers should be equal. Instead README says 3.1 and yubiserve.py says 3.0.

Original issue reported on code.google.com by [email protected] on 31 Mar 2011 at 8:14

Yubiserve cannot last on mysql

What steps will reproduce the problem?
1. Use a mysql server (not a sqlite)
2. Wait 24h without queries
3. Try to use the validation server

What is the expected output? What do you see instead?
The socket fails (empty answer). In fact, the connection was closed by mysql 
for inactivity and since the server only connects once, it then fails.
You need to either detect this disconnection and reconnect, or reconnect by 
default every time a connection is made.

What version of the product are you using? On what operating system?
Up-to-date with gentoo

Original issue reported on code.google.com by Eltrai on 27 Jan 2013 at 12:23

OATH token list traceback

What steps will reproduce the problem?
1. Add OATH key
2. List OATH keys ('dbconf.py -hl')


What is the expected output? What do you see instead?
Expected listing of keys. Got python traceback.

What version of the product are you using? On what operating system?
head

Please provide any additional information below.
./dbconf.py -hl
 1 keys into database:
[Nickname]      >> [PublicID]
Traceback (most recent call last):
  File "./dbconf.py", line 225, in <module>
    print '%-23s >> %-21s >> %s ' %  (nickname, publicname)
TypeError: not enough arguments for format string


Fix: Change line 225 to:
                                        print '%-23s >> %s ' %  (nickname, publicname)

Original issue reported on code.google.com by [email protected] on 14 Aug 2012 at 11:26

Patch for /trunk/dbconf.py

Fixed issue 3 by changing 'true' to 1.

Original issue reported on code.google.com by [email protected] on 23 Feb 2011 at 2:52

Attachments:

• dbconf.py.patch

"while 1" at the end of yubiserve.py

I noticed the :
  while 1:
          time.sleep(1)
at the end of yubiserve.py.

I am not a python expert but that seems not very good.

If you remove :
  http_thread.setDaemon(True)
  ssl_thread.setDaemon(True)

you can remove the "while 1" block with no harm.

Regards

Original issue reported on code.google.com by [email protected] on 12 Mar 2013 at 4:41

[security breach] Making the server fail

What steps will reproduce the problem?
1. Send to the validation server the OTP 
"&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&"
2. Observe how the server does not answer anything

What is the expected output? What do you see instead?
Expected output is BAD_OTP. However, there is no output at all instead.

What version of the product are you using? On what operating system?
SVN version on gentoo

Please provide any additional information below.
The problem might lie in the regex check in yubiserve.py:113. We are not 
checking that the regex actually matched. Indeed, the code seems to expect the 
call to group(1/2) to raise an IndexError and to treat it accordingly.

However, the manual states that such exceptions are only raised if you try to 
get a number higher than the actual number of groups *defined* in the regex. If 
the group exists in the regex but was not found, no exception is generated and 
a None value is returned. Here, the if is therefore false (but nothing is 
raised) and nothing is done.

Original issue reported on code.google.com by Eltrai on 28 Jan 2013 at 8:12

server doesn't test client HMAC for validity

What steps will reproduce the problem?
1. Send incorrect HMAC digest along with request to the server

What is the expected output? What do you see instead?
I would expect the server to reject the request, because the client was sending 
incorrect digest.

This is specified in step 1 of the 'validation server algorithm' on the 
official yubikey-php wiki
1. Val X parses validation request, retrieves the client key for the client id 
from local database and checks the request signature. 

What version of the product are you using? On what operating system?
v3.1 on ubuntu

Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 28 Sep 2011 at 9:40

built for legacy versions of python only

please support python versions 3+

Original issue reported on code.google.com by [email protected] on 15 May 2014 at 2:58

env for shebang

What steps will reproduce the problem?
1. Use a system where the default python interpreter isn't installed in 
/usr/bin or no python interpreter is installed in /usr/bin.

What is the expected output? What do you see instead?
yubiserve should use the default python interpreter but instead uses the python 
interpreter installed in /usr/bin or fails.

What version of the product are you using? On what operating system?
Version 3.1
Platform independent

Please provide any additional information below.
It would be much nice to use "#!/usr/bin/env python" instead.

Original issue reported on code.google.com by [email protected] on 31 Mar 2011 at 7:46

dbconf.py: enable/disable key is broken

What steps will reproduce the problem?
1. Add a yubikey configuration
2. Disable the key using dbconf.py -yd <nickname>
3. Query the server using an OTP from the said yubikey. The server will accept 
it.

What version of the product are you using? On what operating system?
svn trunk (r38)

Please provide any additional information below.
Actually the code in dbconf.py performs wrong queries on the database. The 
attached patch fixes this.

Original issue reported on code.google.com by [email protected] on 25 May 2011 at 8:51

Attachments:

• dbconf-enable-disable.patch

yubiserv doesn't work with Yubico OTP with a public identity greather than 6 bytes.

What steps will reproduce the problem?

./dbconf.py -ya test gncrfhglitkkuunlkrdvtgieiugftjbn e43c17189241 
22e304cd21ec9d0acf80085de096115b

What version of the product are you using? On what operating system?

Version 3.1

Original issue reported on code.google.com by [email protected] on 29 Nov 2013 at 3:48

Code should be simplified!

I've just noticed the code can be simplified and some functions/classes can be 
integrated together. Further analysis are required.
A good idea would be to integrate a function (or a class) to make all the 
checks and try to avoid to execute anything from the huge "if path == 
'/wsapi/2.0/verify'".
Will take care of it asap, but can't give any timeline.

Original issue reported on code.google.com by [email protected] on 8 Feb 2013 at 3:41

When adding a new key, the key is not active.

What steps will reproduce the problem?
1. Add a new key (using sqlite database)
2. Send a query to the server

What is the expected output? What do you see instead?
otp=rcje9u30rnr862234503
status=BAD_OTP
t=2011-01-05T11:20:43

What version of the product are you using? On what operating system?
version 3.0

Please provide any additional information below.
Issue reported by huangmingyou.

Original issue reported on code.google.com by [email protected] on 5 Jan 2011 at 1:59

SQL injection vulnerability

There is a SQL injection vulnerability in the OATH part. The publicID parameter 
is under direct control of the attacker, and given directly to validateOATH 
method without any kind of filtering.

Parameterized statement is the proper way to fix this SQL injection. This idea 
has already been suggested 
(https://code.google.com/p/yubico-yubiserve/issues/detail?id=31) but was 
rejected. Indeed, the patch is not compatible with SQLite and MySQL because the 
paramstyle is different on each supported databases (SQLite, SQLite3 and MySQL).

This patch filters each field of the query string, and should fix this 
vulnerability.

Original issue reported on code.google.com by [email protected] on 9 Jul 2015 at 7:28

Attachments:

• sql.patch

SSL not working with yubico-client

What steps will reproduce the problem?
1. change pam-auth url to use https
2.
3.

What is the expected output? What do you see instead?

expecting validation to succeed
validation fails


What version of the product are you using? On what operating system?

3.1-svn release (current 10/14/2013)
Redhat 6.4

Please provide any additional information below.

I am able to successfully authenticate using the following:

auth        required      pam_yubico.so authfile=/etc/yubikeyid id=1 
key=XXXXXXXXXX= 
url=http://act-yubikey-val.ucsd.edu/wsapi/2.0/verify?id=%d&otp=%s

If I change the url to https it fails. 

Original issue reported on code.google.com by [email protected] on 14 Oct 2013 at 9:13

hwo to let the yubiserve support https ?

I wan't use the yubiserve in production . so I want to know that how to let the 
yubiserve support https ?

Original issue reported on code.google.com by huangmingyou on 13 Dec 2010 at 3:11

support logging

Make use of python logging:

http://docs.python.org/2/library/logging.html#module-logging

Support at least file, stdout and syslog.

http://docs.python.org/2/library/logging.handlers.html#module-logging.handlers

Original issue reported on code.google.com by [email protected] on 20 Mar 2013 at 10:23

Documentational error: 'key' vs 'id' parameter

What steps will reproduce the problem?
1. read the documentation :)

What is the expected output? What do you see instead?

The documentation states for testing OTP with an API key: "To use it, just add 
the 'key=<api key id>'", however, the correct parameter is 'id', as is shown in 
the example which follows: ex.: 
http://192.168.0.1:8000/wsapi/2.0/verify?otp=vvnjbbkvjbcnhiretjvjfebbrdgrjjchdht
bderrdbhj&id=1


What version of the product are you using? On what operating system?
svn checkout r38

Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 6 Aug 2011 at 10:06

Patch for /trunk/dbconf.py

Show status for each yubikeys in database on listing (-yl) command.

Original issue reported on code.google.com by [email protected] on 23 Feb 2011 at 3:02

Attachments:

• dbconf.py.patch

Missing modern TLS security

Hi,

I noticed in the sourcecode that you manually establish TLS connections with 
OpenSSL.

https://code.google.com/p/yubico-yubiserve/source/browse/trunk/yubiserve.py#451

Since every TLS protocol below 1.2 is cryptographically broken you should 
really follow these guidelines when establishing TLS connections 
(https://docs.python.org/3/library/ssl.html), and make sure TLS 1.2 is used and 
established correctly. Since with this specific application there won't be 
problems with e.g. legacy clients, it's easy to switch this part of the 
codebase for a more sound TLS server procedure.

Example code:
https://gist.github.com/azet/09416f8e63b31e0b05d5 (you wan't to use 
non-blocking io though: 
https://docs.python.org/3/library/ssl.html#notes-on-non-blocking-sockets)

Thanks,
Aaron

Original issue reported on code.google.com by [email protected] on 5 Jan 2015 at 8:00

CRC check broken, silently appears to work

What steps will reproduce the problem?
- Just an observation from looking at yubiserve.py

OTPValidation::CRC is missing a line when compared to yubico-c's yubikey_crc16 
function.  That C function does this before looping through each bit:
m_crc ^= (uint8_t) * buf++ & 0xFF;

Notice that OTPValidation::CRC does not consider the value of the variable "b" 
after assigning it.  My suggested change to the function is this line: crc = 
crc ^ (b & 0xff), immediately after assigning b.

A second bug obscures this, in OTPValidation::validateOTP:

if not (self.CRC() or self.isCRCValid()):

That line is going to short-circuit evaluate, because self.CRC() will always 
return a non-false value, so self.isCRCValid() will never be evaluated.

Original issue reported on code.google.com by [email protected] on 26 Oct 2012 at 6:06

Attachments:

• yubiserve.patch

Downloaded python file contains ? on every tabbed line

What steps will reproduce the problem?
1. ./dbconf.py


What is the expected output? What do you see instead?
I expect:
It to work

I get: 
  File "./dbconf.py", line 5
    ?  import MySQLdb
    ^
SyntaxError: invalid syntax

--- Code Snippit ----

def parseConfigFile():?  # Originally I wrote this function to parse PHP 
configuration files!
?  config = open(os.path.dirname(os.path.realpath(__file__)) + 
'/yubiserve.cfg', 'r').read().splitlines()
?  keys = {}
?  for line in config:
?  ?  match = re.search('(.*?)=(.*);', line)
?  ?  try: # Check if it's a string or a number
?  ?  ?  if ((match.group(2).strip()[0] != '"') and (match.group(2).strip()[0] 
!= '\'')):
?  ?  ?  ?  keys[match.group(1).strip()] = int(match.group(2).strip())
?  ?  ?  else:
?  ?  ?  ?  keys[match.group(1).strip()] = match.group(2).strip('"\' ')
------------------------------

What version of the product are you using? On what operating system?
Version 3.1
Fedora 20 x86_64
Python 2.7.5

Please provide any additional information below.
Also, the python mysql python module on my system is imported vi: import mysql 
and not import MySQLdb

Original issue reported on code.google.com by [email protected] on 18 Jun 2014 at 6:00

fallback for sqlite3

What steps will reproduce the problem?
1. Use a more modern system where sqlite3 is used instead of sqlite

What is the expected output? What do you see instead?
The ImportError should be caught and the app should try to import sqlite3 
instead of just crashing.


What version of the product are you using? On what operating system?
3.1
Platform independent.

Please provide any additional information below.
try:
    import sqlite
except ImportError:
    import sqlite3 as sqlite

Original issue reported on code.google.com by [email protected] on 31 Mar 2011 at 7:55

yubiserve fails to listen on IPv6 address

What steps will reproduce the problem?
1. In yubiserve.cfg, change yubiserveHOST from 0.0.0.0 to ::
2. Start the server

What is the expected output? What do you see instead?

Expect: yubiserve.py runs and IPv6 HTTP connections on port 8000 are accepted.

Actual:

    SocketServer.TCPServer.server_bind(self)
  File "/usr/lib/python2.6/SocketServer.py", line 413, in server_bind
    self.socket.bind(self.server_address)
  File "<string>", line 1, in bind
socket.gaierror: [Errno -9] Address family for hostname not supported

server fails to run.

What version of the product are you using? On what operating system?

3.1, on Linux

Please provide any additional information below.

SocketServer.TCPServer doesn't use getaddrinfo() on the listening address to 
get the correct socket type and address family. You can hack yubiserve to 
listen for IPv6 connections by adding a class variable address_family = 
socket.AF_INET6 to BaseHTTPServer, but then it won't work with IPv4 anymore.

Original issue reported on code.google.com by [email protected] on 6 Mar 2012 at 5:47

Problems with authentication using drupal-yubikey

What steps will reproduce the problem?
1. Set up http://code.google.com/p/yubico-yubiserve/
2. Set up drupal with http://code.google.com/p/yubikey-drupal/
3. Try to add your own key to yubikeys in drupal.

What is the expected output? What do you see instead?
Expecting to see the youbikey added (it does with yubico's servers), instead 
getting "YubiKey OTP validation failed with message: NO_VALID_ANSWER"
tcpdump shows that the key was accepted by yubico-yubiserve:
tcpflow -r /tmp/yubi.pcap -c 
192.168.122.049.33032-192.168.122.047.08000: GET 
/wsapi/2.0/verify?id=1&nonce=a27fcf6daf2d50ed02d21ae56da5ffee&otp=cccccccbkkcgcr
gjccrenkdcudgtunljkfkjkbbufbug&timeout=10&h=VR2HaPARxqwHklrAmRPYAGHIg9E= 
HTTP/1.1
User-Agent: PEAR Auth_Yubico
Host: 192.168.122.47:8000
Accept: */*


192.168.122.047.08000-192.168.122.049.33032: HTTP/1.0 200 OK

192.168.122.047.08000-192.168.122.049.33032: Server: Yubiserve/1.0 Python/2.6.6
Date: Fri, 03 Dec 2010 08:41:34 GMT
Content-type: text/plain

otp=cccccccbkkcgcrgjccrenkdcudgtunljkfkjkbbufbug
status=OK
t=2010-12-03T09:41:34
h=r0e+lynY/Dzetl5rYiWU6Orw9HM=


What version of the product are you using? On what operating system?
Most recent on OpenBSD-current on i386 in qemu-kvm.

Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 3 Dec 2010 at 8:43

Exception when using API Key. Patch provided

Hi,

In the last SVN version - revision 39.

What steps will reproduce the problem?
    1. Contact yubiserve.py with OTP and an ID
    2. No response from the server


I added a "try and except" in yubiserve.py between line 224 and 225 and the 
error is : "character mapping must return integer, None or unicode".
I modified the line 225 with str() and it works.


There is an error in the line 213 too. A "&" is missing before "sl="


You'll find in attachment the diff generated with svn.


Regards,

--
Gael Leonet

Original issue reported on code.google.com by [email protected] on 15 Jun 2012 at 4:06

Attachments:

• yubiserve.py.diff

sqlite3 "Cannot continue without any database support."

steps to reproduce the problem?
1. import only "sqlite3" module
2. launch ./yubiserve.py

What is the expected output?
    HTTP Server is running.
What do you see instead?
    Cannot continue without any database support.
    Please read README.

What version of the product are you using?
svn revision 57

On what operating system?
Gentoo

Please provide any additional information below.
    I attached a patch solving this issue.

Original issue reported on code.google.com by [email protected] on 21 Feb 2013 at 9:10

Attachments:

• module_checking.patch

Intermediate CA undetected

What steps will reproduce the problem?
1. Create a certificate where you need an intermediate CA.
2. curl -v https://$SERVER:$PORT/healthcheck?service=all
3. Certificate not valid!!

What is the expected output? What do you see instead?
SSL connection succeeds.

What version of the product are you using? On what operating system?
Trunk, r67 on Ubuntu 12.04.2 LTS

Please provide any additional information below.
                BaseHTTPServer.HTTPServer.__init__(self, server_address, HandlerClass)
                ctx = SSL.Context(SSL.SSLv23_METHOD)
                fpem = os.path.dirname(os.path.realpath(__file__)) + '/yubiserve.pem'
-               ctx.use_privatekey_file  (fpem)
-               ctx.use_certificate_file (fpem)
+                ctx.use_privatekey_file       (fpem)
+                ctx.use_certificate_file      (fpem)
+                ctx.use_certificate_chain_file(fpem)
                self.socket = SSL.Connection(ctx, socket.socket(self.address_family, self.socket_type))
                self.server_bind()
                self.server_activate()

Original issue reported on code.google.com by [email protected] on 23 Apr 2013 at 9:21

support time based oath

It would be very nice to be able to use time based oath tokens, as generated by 
Google authenticator, or similar.

OATH support currently appears to be counter based only.

Original issue reported on code.google.com by [email protected] on 20 Dec 2012 at 7:08

mysql.dump using MyISAM

 Hi,

What steps will reproduce the problem?
1. Look at src/dump.mysql

What is the expected output? What do you see instead?
ENGINE=MyISAM, should be ENGINE=InnoDB

What version of the product are you using? On what operating system?
Browsing the GIT trunk, r67.

Please provide any additional information below.
Is there a reason behind using MyISAM? InnoDB/XtraDB seems to be the more 
future-proof choice.


Cheers, Nafallo

Original issue reported on code.google.com by [email protected] on 23 Apr 2013 at 6:21

typos in dbconf.py

What steps will reproduce the problem?
View the source code of dbconf.py

What is the expected output? What do you see instead?
Cannot disable/enable yubikey in otp and oath mode too.

What version of the product are you using? On what operating system?
yubico-yubiserve-3.0.zip

Please provide any additional information below.
Please find the attached patch, I hope this correct the problem.

Original issue reported on code.google.com by [email protected] on 7 Mar 2011 at 9:42

Attachments:

• dbconf.py__enabledisablekey.diff

support database schema upgrades

Yubiserve ideally needs a way to support database versions, to allow schema 
upgrades.

Maybe one of the tools listed here:

http://stackoverflow.com/questions/3923280/can-you-recommend-a-database-schema-m
igration-tool-that-is-not-tied-to-a-particu

Or: 
https://sqlalchemy-migrate.readthedocs.org/en/latest/index.html

might work.
Or something simple, like 

Original issue reported on code.google.com by [email protected] on 20 Mar 2013 at 10:32

Contributor access

Please may I have contributor access to this project, as I have a patch 
available. See issue 8

Original issue reported on code.google.com by [email protected] on 4 May 2012 at 3:58

PEP8 comliance

What steps will reproduce the problem?
1. Look at the source code

What is the expected output? What do you see instead?
The sources should look much prettier. Instead they look very odd, bulky and 
weird. ;)

What version of the product are you using? On what operating system?
3.1
Platform independent.

Please provide any additional information below.
PEP 8 is a style guide for Python code. Most people of the Python community 
agreed on that style guide and try to come close to it since it improves the 
readability of the code tremendously. And, as we all know, code is much more 
often read than written.

http://www.python.org/dev/peps/pep-0008/

Original issue reported on code.google.com by [email protected] on 31 Mar 2011 at 8:06

version 3.1 dbconf.py corruption

What steps will reproduce the problem?
1. download yubico-yubiserve-3.1.zip
2. unzip
3. inspect or run dbconf.py

What is the expected output? What do you see instead?
Lots of "?" where tabs should be

What version of the product are you using? On what operating system?
3.1 on Linux x86_64, Unicode locale

Please provide any additional information below.
3.0 and trunk are ok

Original issue reported on code.google.com by [email protected] on 12 Apr 2011 at 3:30

Timestamp in OTP is in local timezone instead of UTC

The timestamp returned for Yubikey OTP requests is in the local timezone and 
not in UTC, as expected. The time string is built with strftime() which uses 
localtime() by default.

Here is the fix:

iso_time = time.strftime("%Y-%m-%dT%H:%M:%S", time.gmtime())

Original issue reported on code.google.com by [email protected] on 8 Feb 2015 at 4:05

Multiple SQL injection vulnerabilities

SQL statements are executed with user controlled values inserted. This allows 
for easy SQL injection attacks against the server.

Attached is a patch to correct them. It was only tested against sqlite3 so it 
should probably be tested against MySQL before being committed.

Also included in the patch is a change to the first line to use /usr/bin/env to 
make the script more portable. It can be dropped or added as a different patch 
if needed.

Original issue reported on code.google.com by [email protected] on 16 Aug 2013 at 7:24

Attachments:

• sqlfix.patch