Posted by
frag – April 12, 2010
The Fortis Marathon Rotterdam has been my first marathon finished in 3h:27′:24″ (official time).
I am definitely happy for the result. I considered to run a marathon as a great occasion to sponsor the idea to run for charity .
I published this page as a reference point for those who wanted to read about my goal and donate.
This campaign let me raise 8 wheelchairs (at the time of writing) for which I am proud of.
It kept me on the race – I really thought about that during the marathon – and confirmed what I already knew: I’ve always had great supporters!
Thanks to my parents, my colleagues at DISTRINET, my girlfriend Laura & family, and all my friends who encouraged me during my training period and donated to the cause of IronBubi.
Finishing a marathon definitely changed my life!
Go for it!
Some pictures of this wonderful event here
Posted by
frag – April 3, 2010
Heap-spraying is an interesting type of attack which allocates thousands of malicious objects to the heap in order to exploit a vulnerability of the application (Adobe Reader, Safari, Mozilla Firefox, Internet Explorer). In the presence of a memory corruption or buffer overflow vulnerability, a heap-spraying attack has been shown to be very effective (also with ASLR enabled!).
I wrote a paper to mitigate heap-spraying attacks, now published at SpringerLink. If you find it boring, there are some slides here.
We implemented a prototype in Spidermonkey, the Javascript engine of Firefox. But the concept could be applied to any other application which supports scripting languages a user can consider to spray victim’s memory.
Adobe&Co. guys, please consider this PoC I wrote in a boring and rainy Saturday morning, and fix your things!
Happy Easter!
Posted by
frag – November 2, 2009
When NetBSD and FreeBSD swap out a page from a process, they look in the process virtual address space to find nearby pages that are also candidates for being swapped out. This greatly increases the chance of swapin IO pulling in related data, reducing the number of disk seeks involved in swap IO (from kernelnewbies.org).
I’ve tested the Swapout Clustering patch here and it seems to improve the overall swapping system.
I wrote a benchmark tool to test the swapping system of Linux and collect results.
The benchmark allocates and locks a high amount of physical memory and measures timings of reads and writes to swapped memory.
Actually the parent process sucks all the memory, locks it (unswappable memory) and other 30 processes allocate their own memory to perform reads and writes on.
Three parameters (amount of memory to lock, number of benchmark processes, amount of memory allocated per process) can be tuned to perform a reasonable benchmark on different systems.
Results have been collected on a virtual machine running in KVM, with 128MB RAM.
The benchmark tool has been launched by locking 110MB of physical memory; 30 processes performed reads and writes on a 10MB memory space.
Build and run with
make swapbench
./swapbench -a 110 -p 30 -l 10
Set a reasonable amount of memory to lock and force the system to swap benchmark processes’ memory in and out.
Results
I run the benchmark many times to collect reliable results on a Kvm virtual machine with 128MB Ram, Intel Core2Duo processor and the kernel versions reported in the table below:
| kernel version |
Avg. read (s) |
Avg. write (s) |
Overhead read |
Overhead write |
| linux-git 2.6.32-rc5 |
0.560072201681
|
0.560865798319
|
%
|
%
|
| linux-git-swapoutclustering-patch |
0.433929222689
|
0.43047510084
|
-23%
|
-23%
|
Download
The source code of the benchmark as well as the collected results is available for download.
| Filename |
Description |
Download |
| swapbench.c |
Source code of the benchmark tool (not complete but fully functional) |
here |
| bench_swap_cluster.txt |
Results collected from linux-git |
here |
| bench_swap_cluster_patch.txt |
Results collected from linux-git-cluster-patch |
here |
| readstats.py |
Python utility to compute averages from result files |
here |
Posted by
frag – July 29, 2009
A recent research paper in the field of P2P technology has been published and considered the “most effective” solution to kill P2P as it is intended nowadays. The research comes indeed with the scary title Proactive Content Poisoning To Prevent Collusive Piracy in P2P File Sharing.
It consists in injecting fake pieces of files to not authorized peers (users who didn’t pay the fee to download) who will never download the complete file, of course (they will download it in infinite time… ok engineers…:) ).
Thing is that the BitTorrent protocol is not affected by this kind of protection since each piece is checked with the SHA1 of the metainfo file (the .torrent file you download from thepiratebay.org…). Moreover all modern BitTorrent clients try to download chunks (parts of a piece for which the SHA1 exists) of the same piece from the same peer. This would prevent a peer to stay anonymous when he will inject a fake chunk. At the first occasion, when the complete piece can be checked, if the checksum fails, that peer is banned from the peerlist.
(Why not informing the tracker with a hey-this-is-a-bad-guy message? I think this can be a protocol extension).
Full paper can be downloaded here.
Another great magic trick of the BitTorrent protocol (although it needs improvements) or just another pompous strategy to prevent filesharing?
Copyright 2009 Francesco Gadaleta 
