Cores and Extras Heliotropic Computing

Thursday Oct 30, 2008

Solaris provides a cryptographic framework to it's users. There are different providers like user level , kernel level and even hardware level are available. Different kind of algorithms are used like symmetric , asymmetric or hash functions. While using a cryptography algorithm to secure some confidential data one thing must be keep in mind that weak algorithms may break all security measures and make confidential data available to some unauthorized user. There are many third party password encryption algorithms available in the web. Someone can download and install it through 'pkgadd' and use it by editing '/etc/security/crypt.conf' , '/etc/security/policy.conf' etc. But using a non-standard algorithm is dangerous because it's very much vulnerable to attack and intruders can easily gain access to a system by deciphering through those algorithms.
So password protection and other valuable data protection must be done by a widely used , well known and well standard encryption algorithm only. It's recommended to use algorithms which uses keys that are at least 128 bits in length for adequate security.
Weak hash functions also bring same kind of threats as reversible hash functions can be exploited by an intruder to determine the original input and gain access to a system. So while using any kind of cryptographic framework , an user must be very careful as it may cause serious security problems in a system.

I can easily remember those days when I started learning J2EE and web technology. Database connectivity with a jsp / servlet  page often done by the following kind of code :
Connection con = DriverManager.getConnection(url , usrname, passwd);
This is an example of hard coded passwords where the actual password is used in the code to do some task. Hard coded passwords and cryptographic keys always increase the chance of security related problems.This kind of coding is not secured, first of all someone can use the generated class file with 'javap -c' and recover the password, username ... basically everything he wants to know. The password can't be changed without a patch , The whole developer team need to know the password , an unauthorized user who knows the password can easily gain access to the system ,  moreover the password will remain same across various companies and organizations who are using that product.

Same kind of security threat may come from hard coded cryptographic keys. It's not a tough job for an unauthorized user to gain access through questions where hard coded cryptographic keys are used. Using a hash function also won't be a safer idea as most of them are reversible and vulnerable to attack.

For more detail information and references , Check out :
http://cwe.mitre.org/data/definitions/259.html
http://cwe.mitre.org/data/definitions/321.html


We use Syslog to report system events. Now if you want to prevent unauthorized access to your system , monitoring logins is mandatory. Syslog provides an option to monitor failed logins . As a system administrator you may use '#logins -x -l username' to check login status of a particular user. But if you want to check failed logins to detect a potential threat about unauthorized access you need to take some easy steps. Before proceeding to those steps , some idea about a system file i.e '/etc/syslog.conf' is necessary.
Open the file , you will find some lines like :

*.err;kern.notice;auth.notice                   /dev/sysmsg
*.err;kern.debug;daemon.notice;mail.crit        /var/adm/messages

*.alert;kern.err;daemon.err                     operator
*.alert                                         root

*.emerg                                         *

Here the first field is Selector field and second field is Action field. Each line is written as Selector <Tab> Action ..in this way.  Selector field has again two parts , facility and level . They are written as facility1.level1:facility2.level2:facility3.level3 ..in this way. Action field determines where the message will be forwarded. Here *.err means error from any facility , kern stands for kernel , crit for critical etc. Detail description about facilities and levels is available here.
Now let's come back to the steps to detect failure logins.

i) edit /etc/default/login
here you can change the default values of TIMEOUT, SLEEPTIME, DISABLETIME, RETRIES etc. Make sure SYSLOG=YES is mentioned there. Now if you want to log a message after a single unsuccessful login attempt then make 'SYSLOG_FAILED_LOGINS=0'.

ii) create a log file : #touch /var/adm/faillog , give appropriate permission : chmod 600 /var/adm/faillog , select suitable group : chgrp sys /var/adm/faillog.

iii) edit /etc/syslog.conf
add a line : auth.notice<Tab>/var/adm/faillog

iv)then execute ' svcadm refresh system/system-log'.


Also check out man logger to know how to add entries to the system log, man  syslogd to log system messages and man logadm to manage endlessly growing log files.

Friday Oct 24, 2008

NetBeans.org  has announced the availability of NetBeans IDE 6.5 RC1. You may like to check out the following links:

The focus of NetBeans IDE 6.5 is simplified and rapid development of web, enterprise, desktop, and mobile applications with PHP, JavaScript, Java, C/C++ , Ruby, and Groovy. New features for 6.5 include a robust IDE for PHP, JavaScript debugging for Firefox and IE, and support for Groovy and Grails. This release also offers a number of enhancements for Java, Ruby and Rails, and C/C++ development. Java feature highlights include: built-in support for Hibernate, Eclipse project import, and compile on save. The Release Candidate improves on the support offered in NetBeans 6.5 Beta.

So just check it out ... it would be a nice experience !! 

Very often we need to create temporary files while creating a large piece of code. Common C library functions like tmpnam(), tempnam(), mktemp() etc are used to generate a unique name for a temporary file. These functions doesn't open that file. Other C functions like tmpfile(), mkstemp() are also available which generates a unique name for a temporary file as well as open that file. Now those name-generating-only functions are very much vulnerable to attack. There are several reasons behind that . Those functions generate random unique names for temporary files which are not too difficult to guess. So if an attacker can guess the file name and create a duplicate same-named filed between name generation and file opening process execution then it may cause serious security problems depending on file permissions and opening options . This is another aspect to keep in mind , file permission during creation and directory permission where those files would be stored ($ env | grep TMPDIR) must be set up with proper permissions to avoid security threats. So finally we can conclude that perhaps mkstemp() is the safest way to create temporary files as it creates and opens a unique file based on a filename template provided by the user combined with a series of randomly generated characters.

More detail information is available on Common Weakness Enumeration website.