Hi all,
We are running FreeRADIUS 1.1.6 on Solaris 10 (sparc) and want to
retrieve authorization information from an Pervasive SQL database via an
ODBC Bridge.
In order to do so we installed on our Solaris host:
- the unixODBC ODBC Manager 2.2.12
- Easysoft ODBC-ODBC Client 32bit for Solaris
But every time a RADIUS request was processed and a valid SQL query was
send via module rlm_sql_unixodb to the SQL database, both RADIUS and the
remote ODBC server crashed. Error in radiusd: memory allocation.
It took quite some debugging to find the cause of this. In the driver
rlm_sql_unixodbc, in file sql_unixodbc.c we found the following code:
===============
static int sql_num_fields(SQLSOCK *sqlsocket, SQL_CONFIG *config) {
rlm_sql_unixodbc_sock *unixodbc_sock = sqlsocket->conn;
long err_handle;
int num_fields = 0;
err_handle =
SQLNumResultCols(unixodbc_sock->stmt_handle,(SQLSMALLINT *)&num_fields);
if (sql_state(err_handle, sqlsocket, config))
return -1;
return num_fields;
}
===============
SQLSMALLINT is defined in unixODBC, file: include/sqltypes.h
typedef signed short int SQLSMALLINT;
But num_fields is of type 'int' !
This caused the function to return 0x20000 instead of 0x001, which in
turn caused both the radiusd and the remote ODBC server to allocate
memory for 0x20000 (131072) rows!
I simply changed this piece of code to:
===============
static int sql_num_fields(SQLSOCK *sqlsocket, SQL_CONFIG *config) {
rlm_sql_unixodbc_sock *unixodbc_sock = sqlsocket->conn;
long err_handle;
SQLSMALLINT num_fields = 0;
err_handle =
SQLNumResultCols(unixodbc_sock->stmt_handle,&num_fields);
if (sql_state(err_handle, sqlsocket, config))
return -1;
return num_fields;
}
===============
This solved our crashes.
So the solution only involved changing the type of num_fields to
SQLSMALLINT (the same as required by the SQL call SQLNumResultCols) and
removing the type cast in the actual call to SQLNumResultCols
(unnecessary now).
After we solved it this way, I found the same error fixed in a similar
way on a SUSE distribution list:
http://lists.opensuse.org/opensuse-commit/2007-05/msg00099.html
I believe this to be a small error in the rlm_sql_unixodbc Driver.
Hopefully other people can benefit from our experience.
Can anyone confirm that my solution is correct and should work for all
OS's (as I expect) even though this might not cause problems on all OS's
(as on some, a short int is just as big a normal int)? Then I will send
in a bugreport via the site.
Kind regards,
Erik Plaggenmarsch
ÿþD i t b e r i c h t i s v e r t r o u w e l i j k e n k a n
g e h e i m e i n f o r m a t i e b e v a t t e n e n k e l
b e s t e m d v o o r d e g e a d r e s s e e r d e . I n d i e n
d i t b e r i c h t n i e t v o o r u i s b e s t e m d ,
v e r z o e k e n w i j u d i t o n m i d d e l l i j k a a n
o n s t e m e l d e n e n h e t b e r i c h t t e
v e r n i e t i g e n .
A a n g e z i e n d e i n t e g r i t e i t v a n h e t
b e r i c h t n i e t v e i l i g g e s t e l d i s m i d d e l s
v e r z e n d i n g v i a i n t e r n e t , k a n A t o s
O r i g i n n i e t a a n s p r a k e l i j k w o r d e n
g e h o u d e n
v o o r d e i n h o u d d a a r v a n .
H o e w e l w i j o n s i n s p a n n e n e e n v i r u s v r i j
n e t w e r k t e h a n t e r e n , g e v e n
w i j g e e n e n k e l e g a r a n t i e d a t d i t
b e r i c h t v i r u s v r i j i s , n o c h a a n v a a r d e n
w i j
e n i g e a a n s p r a k e l i j k h e i d v o o r d e
m o g e l i j k e a a n w e z i g h e i d v a n e e n v i r u s i n
d i t
b e r i c h t .
O p a l o n z e r e c h t s v e r h o u d i n g e n ,
a a n b i e d i n g e n e n o v e r e e n k o m s t e n
w a a r o n d e r
A t o s O r i g i n g o e d e r e n e n / o f d i e n s t e n
l e v e r t z i j n m e t u i t s l u i t i n g v a n a l l e
a n d e r e v o o r w a a r d e n d e
L e v e r i n g s v o o r w a a r d e n v a n A t o s O r i g i n
v a n t o e p a s s i n g .
D e z e w o r d e n u o p a a n v r a a g d i r e c t
k o s t e l o o s t o e g e z o n d e n .
T h i s e - m a i l a n d t h e d o c u m e n t s a t t a c h e d
a r e c o n f i d e n t i a l a n d i n t e n d e d s o l e l y
f o r t h e a d d r e s s e e ; i t m a y a l s o b e
p r i v i l e g e d . I f y o u r e c e i v e t h i s e - m a i l
i n e r r o r , p l e a s e n o t i f y t h e s e n d e r
i m m e d i a t e l y a n d d e s t r o y i t .
A s i t s i n t e g r i t y c a n n o t b e s e c u r e d o n
t h e I n t e r n e t , t h e A t o s O r i g i n g r o u p
l i a b i l i t y c a n n o t b e t r i g g e r e d f o r t h e
m e s s a g e c o n t e n t . A l t h o u g h t h e
s e n d e r e n d e a v o u r s t o m a i n t a i n a
c o m p u t e r v i r u s - f r e e n e t w o r k , t h e s e n d e r
d o e s n o t w a r r a n t t h a t t h i s t r a n s m i s s i o n
i s v i r u s - f r e e a n d w i l l n o t b e
l i a b l e f o r a n y d a m a g e s r e s u l t i n g f r o m
a n y v i r u s t r a n s m i t t e d .
O n a l l o f f e r s a n d a g r e e m e n t s u n d e r
w h i c h A t o s O r i g i n s u p p l i e s g o o d s a n d / o r
s e r v i c e s o f w h a t e v e r n a t u r e , t h e T e r m s
o f D e l i v e r y f r o m A t o s O r i g i n
e x c l u s i v e l y a p p l y .
T h e T e r m s o f D e l i v e r y s h a l l b e p r o m p t l y
s u b m i t t e d t o y o u o n y o u r r e q u e s t .
A t o s O r i g i n N e d e r l a n d B . V . / U t r e c h t
K v K U t r e c h t 3 0 1 3 2 7 6 2
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
