Pages

08 July 2012

Fixing segfault in Pathload

Dear readers

Couple days ago (it's 1st week of July 2012), I came across this nifty tool called Pathload. Essentially, it helps you determine the real upstream and downstream connection of yours.

Inaccidentally, when I tried to run it, it segfaulted immediately. With a bit help of gdb and trial/errors, I found and fix the bug. Here's the complete email message that I sent to its maintainer (which is I find no longer maintain it anymore) describing the problem. For those who just seek for the patch, just scroll to the end of this post (normal patch format):

Dear Constantinos

I came across this nice tool Pathload of yours today while exploring
about network management in Linux kernel. Of course, quickly I
downloaded the link to the source tarball (I use Linux -- Centos 5.x)
and compiled it.

When running it, it suddenly stopped due to segfault. After checking
the stack trace in the resulting core dump image, it leads to line 132
in client.c:
  strcpy(serverList[i],buf);

My intuition suddenly told me it must out of bound char copy. Short
story short, I landed to client.h at this line:
#define MAXDATASIZE 25 // max number of bytes we can get at once

I did quick test and change the above line. Now it reads
#define MAXDATASIZE 50

I do "make clean" followed by "make". Now it runs perfectly fine as
far as I can tell.

Hopefully it means something to you for upcoming release. Meanwhile,
once again thank you for this piece of good work.

PS: strangely, without modifying any single line of source code, the
resulting binary worked fine inside GNU debugger (gdb). That's why I
suspected a race condition initially.

--- client.h.old    2012-07-07 11:10:54.000000000 +0700
+++ client.h    2012-07-07 11:10:37.000000000 +0700
@@ -62,7 +62,7 @@
 #define UNCL    4

 #define SELECTPORT 55000 // the port client will be connecting to
-#define MAXDATASIZE 25 // max number of bytes we can get at once
+#define MAXDATASIZE 50 // max number of bytes we can get at once
 #define NUM_SELECT_SERVERS 3

 EXTERN int send_fleet() ;

30 March 2012

"useradd" and "adduser" are the same? think again....

Well, actually they are not that different. Only small not-so-obvious-but-a-bit-bothering fact.

I did this in Ubuntu Natty (11.04):
sudo useradd -m user_a

and next:
sudo adduser -m user_b

Of course I put password on both of them, let's say "123456" (weak one, I know :) ). And then, if I did:
su - user_a
I got:
$
Just plain dollar sign. "Uhm, what's wrong?".

But, if I did:
su - user_b
I got:
user_b@localhost $

Grrrr.... I quickly concluded that something is different in their bash initialization. So a quick:

sudo diff -Naur /home/user_a/ /home/user_b/
should pin point the difference if there are any, right away. But I was wrong. They were exactly identical.

Then I decided to take a peek at /etc/passwd. No strong reason though, just plain curiousity:
grep -E 'user_a|user_b' /etc/passwd
the result:
user_a:..........:/bin/sh
user_b:..........:/bin/bash
[The passwd entries are shortened to focus on the important fields only]

Great! We found it! "But wait, isn't that /bin/sh a symbolic link to /bin/bash?". Well yes, at least sometimes ago. But recently, at least on latest releases of Ubuntu and its derivatives, /bin/sh is now pointing to "dash".

Dash is a "bash" alike shell but with smaller file size and fewer capability, which result to incompabilities with Bash in many aspects. So, no wonder that ".bashrc" didn't initialize the shell prompt along with other thing (enabling Tab completion, IIRC) correctly.

Therefore, to fix the useradd behaviour, simply use:
sudo useradd -s /bin/bash user_a

Another case closed, folks :)

PS: It's really a wonder how much you can do with grep and diff, if you know where to look ..... :D

NB:

regards,

Mulyadi Santosa

25 January 2012

"libc.so.6 not found"? here we go again...

Hi all...

I've been tinkering with Linux Mint for the last month, so my CentOS installation was kinda abandoned. However, I took my chance to update CentOS via the usual chroot trick. It works.... however...

I found a glitch. I was aware of it when I ran my self-made wifi connection script which calls dhclient program. It said:
libc.so.6 not found

Great...ldd said the same thing too. However, libc.so.6 is still in /lib/libc.so.6, so it's not really missing. Hmmmm...

As a important note: recent update shows that there is another libc.so.6 which reside in /lib/i686/nosegneg. From random googling, I concluded that it is a "Xen friendly" library. It's a short way to describe that those libraries are not using certain segmentation techniques that might confuse or break Xen, so to speak.

Then, somehow I felt that it *might* be related to SELinux (i make it enforcing). Here are few lines from /var/log/messages that shows such quirk:
kernel: [    5.195941] type=1400 audit(1327499418.190:3):
 avc:  denied  { read } for  pid=860 comm="restorecon" name="libc.so.6" dev=xxxx ino=4821369 scontext=system_u:system_r:restorecon_t:s0 tcontext=system_u:object
_r:file_t:s0 tclass=lnk_file

and the output of "ls" is:
$ ls -lZ /lib/libc.so.6
 
lrwxrwxrwx  root root system_u:object_r:file_t          /lib/libc.so.6 -> libc-2.5.so
(the above output might be slightly incorrect, just focus on "file_t" attribute)

Alright, so SELinux attribute of libc.so.6 is wrong. I didn't know what exactly causing that during the chroot session. My best guess is that since it was done inside Linux Mint, which in turn doesn't use SELinux, partial relabeling or anything related to fix SELinux attribute simply fails.

The fix is fortunately easy:
1. edit /etc/sysconfig/selinux. change "SELINUX=enforcing" into "SELINUX=permissive"
2. do "sudo touch /.autorelabel". Notice the . (dot) prefix.
3. reboot

SELinux will relabel everything inside your mounted filesystem according to its default configuration once Linux enters normal runlevel.

To confirm your problem is gone, pick random binary, say dhclient and run ldd. Here's mine:
$  ldd /sbin/dhclient
libc.so.6 => /lib/i686/nosegneg/libc.so.6


And problem is solved :) Now you can turn SELinux back into enforcing mode.

PS: SELinux is both fun and frustating..... but with careful log analysis, usually you can pinpoint the root of the problem pretty fast.

regards,

Mulyadi Santosa

18 November 2011

The correct gcc parameter for Intel Core Duo

On the quest of optimization....

One thing that bugs my mind lately is: which architecture Intel Core Duo uses? If we read this Wikipedia entry, one will quickly conclude that it is "enhanced" Pentium M.

So, does gcc agree with it? Not really. Using the idea taken from this blog entry, Core Duo is a Prescott! Here's the output:

/usr/lib/gcc/i486-linux-gnu/4.4.3/cc1 -E -quiet -v - -D_FORTIFY_SOURCE=2 -march=prescott --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=2048 -mtune=generic -fstack-protector

Surprisingly, this is indeed correct. Gentoo's wiki page support this, even Intel's engineer puts amen.

Summary: I conclude, Core Duo it's Yonah (Pentium M), but optimization wise, assume it's Prescott.

regards,

Mulyadi Santosa

03 October 2011

hashing? great.... which one?

Hi folks....

hashing is quite large subject. I myself simply use hash to confirm whether two files (or more) are identical or not (using md5sum, sha256sum).

But as the books say, hashing could has collisions. And hashing, one way or another, could be reversed. or in other word, there is no such perfect true one way hashing. Alright, we can't pursue perfection here. So what's the recipe to pick the best hashing method?

Fortunately, an article written by Valerie Aurora gives us the clue. For the impatient, you better use something like SHA-2 (sha256 or better). I found the article nicely explain the issues behind hashing with quite friendly (read: non hacker-ish) tone :)

Cheers and have a nice day ....

regards,

Mulyadi Santosa

02 July 2011

Feedback regarding my "stat or ls" post

Hi all

Several people are kind enough to share her/his thoughts about my "stat or ls" post. One of them even share this forum post. Quite neat I must say!

Basically they said that both "ls" and "stat" output are correct. One even compare it with "du" output (by default, "du" is using block size unit when showing file size).

What I might failed to stress was, the tests done in my last post was done on top of SELinux enabled-ext3 filesystem. "So what?" you might ask. Briefly maybe none. But my friend pointed that stat was accouting extra blocks that might (I say "might" because my friend is not so sure) contain metadata such as SELinux and ACL.

So far, I find it consistent that the used blocks reported in "ls -ls" is always half of one reported by "stat". It must be something related to return value of function I stated in my previous post. 1KiB? hmmmm......

PS: Further info regarding by block device and filesystem. Thanks to Justin Cook who pointed me to this neat tool:

# blockdev --getbsz /dev/sda3
4096
# blockdev --getss /dev/sda3
512
The first is my fs block size, the latter is my disk sector size.

regards,

Mulyadi Santosa.

01 July 2011

stat or ls? which one showing correct number of used block?

The answer: stat!

(credits to Manish Katiyar who helped me tinkering with the codes.... click here to find out more about him)

Why? OK, suppose we create a test file like this:
dd if=/dev/zero of=doang.img bs=1K count=3

And then we run both ls and stat against it:
$ stat doang.img
  File: `doang.img'
  Size: 3072            Blocks: 16         IO Block: 4096   regular file

$ ls -ls doang.img
8 -rw-rw-r-- 1 mulyadi mulyadi 3072 Jun 30 12:36 doang.img

"what the @#$%?" Yeah I suppose you would say that. stat is saying the file is using 16 blocks while ls says 8 (leftmost one). Both couldn't be true, right?

Strace comes to rescue. Stracing both of them would yield something like this:

lstat64("/home/mulyadi/doang.img", {st_dev=makedev(8, 5), st_ino=1304650, st_mode=S_IFREG|0664, st_nlink=1, st_uid=500, st_gid=500, st_blksize=4096, st_blocks=16, st_size=3072, st_atime=2011/06/30-12:36:40, st_mtime=2011/06/30-12:36:40, st_ctime=2011/06/30-12:36:40}) = 0

lstat/fstat/stat is glibc function which fetch inode information about a file. In turn it will call stat syscall.

According to "man 2 stat", st_blocks denotes the number of blocks allocated for target file. So, we could directly say stat shows correct number.

But wait... why does ls show us 8? To find out, you need debuginfo of coreutils package or download coreutils package and compile by yourself. I assume you pick the latter. By default, compilation will leave debugging-ready binary in its source directory.

To make story short:
$ gdb src/ls
(gdb) b default_block_size
Breakpoint 1 at 0x80553e6: file human.c, line 407.
(gdb) r -ls ~/doang.img
Starting program: /home/mulyadi/Download/SOURCE/coreutils-8.12/src/ls -ls ~/doang.img
[Thread debugging using libthread_db enabled]

Breakpoint 1, default_block_size () at human.c:407
407       return getenv ("POSIXLY_CORRECT") ? 512 : DEFAULT_BLOCK_SIZE;

So, the above function would yield the "correct" block size which will be used for further computation. Guess what it returns?

(gdb) finish
Run till exit from #0  default_block_size () at human.c:407
0x0805553c in humblock (spec=0x0, opts=0x805feb0, block_size=0x805feb8)
    at human.c:419
419         *block_size = default_block_size ();
Value returned is $1 = 1024

Tada............. 1024 bye a.k.a 1 KiB ladies and gentlemen! That's why you see 8. It's 16*512/1024 = 16/2 = 8! Solved!

PS: this means my system, in this case ( a CentOS 5.x ) is not POSIX-ly correct. Not sure if that's a bad news or good news... :)

Conclusion: take any command's output with a grain of salt. Trusting them blindly sometimes might mislead yourself into wrong information. You have been warned.

regards,

Mulyadi Santosa.

27 June 2011

A nice interactive tutorial to learn how XSS works

Hi folks....

XSS (Cross site scripting) has been all over the news about security and I am sure you've heard about it even a bit. So, you must be curious on how it works....and more important is how to detect and fix such problem.

I came across this nice tutorial few days ago. I found it as simple, straight to the point and easy to follow....even for someone new in security field but at least has grab some root of web development. The author is Steve Kemp and it seems he has some talents regarding security (he released some advisories).

Follow the links...read through the steps. Starting from reintroduction of what cookies is, how javascript could be used to read such info, then a simple intro about public forum text box that can be misused to display embedded javascript and eventually finished by a general recipe on how to prevent such problem (hint: some scripting modules can "wash out" unexpected characters).

Enjoy ............ :)

regards,

Mulyadi Santosa.

19 April 2011

Getting confused when exploring Qemu source? gcc comes to rescue!

Quick summary first: use gcc -save-temps!

Ever dig into Qemu (qemu.org) source code? OK, I assume you ever did that at least once... may I ask, what's your first impression?

Here's mine: it's complex C code...and to make it more like a nightmare, it heavily uses c (gcc, to be precise) tricks almost everywhere. ifdef, "##", define....almost endless. IMHO, since Fabrice Bellard, its author, is somekind of C compiler wizard, he somehow pull out all of those tricks so easy from his mind. I know it should make the code kinda more readable, but for me, is not.

Take one for example: INDEX_op symbols. AFAIK, it has something to do with code generation, to be precise it's an index toward instruction op which will later be translated to target. Previously, I thought it was defined somewhere in header files, but turns out (after long hours of grep and cscope sessions) they were created by preprocessor (token concatenation, to be precise -- explanation here).

So, what is the recipe? I think I found it (thanks to this URL http://stackoverflow.com/questions/3812670/what-are-the-internal-processes-involved-for-a-c-compilation/3814007#3814007) , although not really ideal. During configuration session, use extra cflags like this:
./configure --extra-cflags="-save-temps"
Put additional parameters as needed. Then do "make". Now, if you do this in main Qemu source tree:
find -iname "*.[is]"
you'll find several files. Each of them are result of  preprocessing (.i) and assembling (.s). Yeap, "-save-temps" comes to rescue, folks! So there you go... open them one by one and hopefully you get better picture on how to code works.

regards,

Mulyadi Santosa

04 April 2011

Troubleshooting failed login to GTalk in Empathy 2.30.3

Alright, I just wanna make it quick:
- Check "Ignore SSL certificate errors"
- Uncheck "Encryption required (TLS/SSL)"
- Use "443" as port
- Check "use old SSL"

OK, that's it people...it works for me, hopefully it works for you too. Cheers...

regards,

Mulyadi Santosa