Cette mise a jour corrige plusieurs failles de sécurité importantes, et corrige également des bugs dans l’encodage h264. Vous allez donc enfin pouvoir encoder en mpeg-4 sous windows pour, entre autre, votre iPhone

Le changelog complet ici : http://trac.videolan.org/vlc/browser/tags/0.8.6e/NEWS

Mettez vite a jour pour éviter tout probleme de sécurité. Merci à la team VLC !

Voici une procédure simplifiée que j’ai suivie sur une debian avec un kernel dedibox r5 :

* apt-get update && apt-get upgrade : mettre a jour les packages pour le nouveau noyau. Attention, cette étape peut vous forcer à passer à MySQL5 et PHP5

* installation du nouveau kernel : apt-get install linux-image-2.6.18-6-686

* reboot puis uname -r pour voir si tout va bien : Linux xx_xx 2.6.18-6-686

Si votre machine ne redemarre pas, essayez un reboot materiel via la console et au pire, bootez sur le system de secours pour modifier /boot/grub/menu.lst et remettre votre ancien noyau (parametre ‘default’).

Ce patch est indispensable sinon tot ou tard votre systeme sera compromis.

Pour ceux qui souhaiterait installer leur propre kernel et le patcher, suivez le tuto de drax sur son (excellent) blog : vmsplice-exploit-fix-and-patching-on-debian et pour les plus curieux, plus de détails techniques sur cette faille : http://www.isec.pl/vulnerabilities/isec-0026-vmsplice_to_kernel.txt

Yuck. What’s more, if you’re using SuExec (like I am) then your Apache directives are ignored.

Solution: Edit your trac.fcgi and prepend the following code.

# hack for SuExec
import os;
os.environ['TRAC_ENV_PARENT_DIR'] = '/var/lib/trac'

Affected versions: >= 2.6.17
Fixed in version: 2.6.24.2

Fix

You can download the vmsplice patch locally or from the official LKML thread: [PATCH] vmsplice exploit fix

Patching on Debian Etch

Update 12/02/08: Debian repositories have been updated and contain patched kernels. If you’re using a stock kernel, the following two commands should sort you out (providing you reboot afterwards).

aptitude update
aptitude upgrade

Install kernel sources

export KVER=`uname -r`
aptitude update
aptitude install linux-source-${KVER}
cd /usr/src
tar -xjf linux-source-${KVER}.tar.bz2
ln -s linux-source-${KVER} linux
cd linux

Patch kernel sources

patch < vmsplice.patch -p1

Compile kernel and install

You'll want to copy your existing kernel configuration.

cp /boot/config-${KVER} .config
make-kpkg clean
make-kpkg --initrd --append-to-version=-mykernelname kernel_image
cd ..
dpkg -i linux-image-${KVER}-mykernelname_${KVER}-mykernelname-10.00.Custom_i386.deb
reboot

References

• http://www.isec.pl/vulnerabilities/isec-0026-vmsplice_to_kernel.txt
• http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=465246
• http://milw0rm.com/exploits/5092
• http://milw0rm.com/exploits/5093

TrueCrypt, probably the best solution available, was only working on Linux and Windows… up to now.

Some dude got impatient for the OS X port, managed to make a deal with a developper to code it for 1500$, raised those 1500$ and BAM! Bob’s you’re uncle.

The software is labelled alpha, described as beta, and used in production… w00t. Jokes aside, it’s been released for a few weeks now and no serious data-destroying bug stories have arose. Nevertheless, you might want to backup to another more trusted encrypted disk somewhere, every now and then.

Bare in mind the TrueCrypt team annouce their 5.0 release for the 4th of Febuary 2008 (that’s in 2 days) and claim OS X support. Watch this space…

Still interested? Download the software here:

• TrueCrypt for OS X
• TrueCrypt for Linux and Windows

OS X notes:

• Your encrypted filesystem image should have a .img extension.
• When mounting a hidden volume, you’ll be asked the outer volume password, then the hidden volume password.
• Unmounting in finder does not dismount the image. It’s a known bug. Use ocutil -detach.

Seule solution pour se protégér : utiliser NoScript, ou, mieux, passer sous Lynx

La (longue) liste des plugins permettant cette exploitation : https://bugzilla.mozilla.org/attachment.cgi?id=300181

Ca me rappelle le bug affectant FireBug   http://www.frsirt.com/bulletins/9835

HTTPS is just HTTP encapsulated inside an SSL tunnel. Apache’s virtual hosts are a clever “hack” whereby the Host header in the HTTP packet is verified. This alllows a single apache instance on a single IP/Port combination to serve a (not so) infinite number of differentes sites (aka vhosts).

Problem: The SSL tunnel is created before the first HTTP packet gets sent. Apache needs an SSL certificate but doesn’t have a Host header to match, hence cannot choose a virtual host.

Solution

This trick essentially does the matching of the Host header after the SSL connection has been established. How? Via some mod_rewrite magic!

Caveats

Although I said so, it’s not really that magical. There are a few things this trick does not solve.

• The SSL certificate used will be common to all SSL vhosts.
• Certain Apache directives may be common to all SSL vhosts (example: SuExecUserGroup). Basically anything you can’t override in a .htaccess file will be shared amongst vhosts.

The trick

The process is only 2 steps and involves modifying your Apache configuration. I assume you have a working SSL vhost configured.

1. Create virtual hosts “map file”.
2. Modify existing SSL vhost.

1. The virtual hosts map file

Create a new file in your Apache server root. Example:/etc/apache2/ssl.map

Write a list of virtual hosts and their respective DocumentRoot. Example:

foo.example.com        /var/www/foo.example.com/
bar.example.com        /var/www/bar.example.com/
# you can even put comments!
# Alias to bar
boar.example.com        /var/www/bar.example.com/

2. Edit your SSL vhost

Open your Apache config, inside the <VirtualHost> section of your SSL vhost, include the following code or include this file: Mass SSL vhosts Apache config.

Important: Make sure to edit line 8 to include the correct path to your ssl.map file.

### Mass SSL Vhosts ###
RewriteEngine on

#   define two maps: one for fixing the URL and one which defines
#   the available virtual hosts with their corresponding
#   DocumentRoot.
RewriteMap    lowercase    int:tolower
RewriteMap    vhost        txt:/etc/apache2/ssl.map

#   1. make sure we don't map for common locations
RewriteCond   %{REQUEST_URI}  !^/cgi-bin/.*
RewriteCond   %{REQUEST_URI}  !^/icons/.*

#   2. make sure we have a Host header
RewriteCond   %{HTTP_HOST}  !^$

#   3. lowercase the hostname
RewriteCond   ${lowercase:%{HTTP_HOST}|NONE}  ^(.+)$
#
#   4. lookup this hostname in vhost.map and
#      remember it only when it is a path
#      (and not "NONE" from above)
RewriteCond   ${vhost:%1}  ^(/.*)$

#   5. finally we can map the URL to its docroot location
#      and remember the virtual host for logging puposes
RewriteRule   ^/(.*)$   %1/$1  [E=VHOST:${lowercase:%{HTTP_HOST}}]

Restart Apache and you’re done. You should be able to browse (in https) the vhosts you added to your ssl.map file.

Grandma says: You don’t need to reload Apache when you edit your map file. Just create the document root folder on the filesystem, add a new entry to your map and you’re good to go.

Panique à bord ce matin dans de nombreuses entreprises qui utilisent leur smtp perso !  Et bien sur la hotline est submergée et on vous raccroche gentillement au nez;(

Switchez donc sur smtp.wanadoo.fr le temps de pouvoir désactiver ce vilain bridage.

This post is password protected. To view it please enter your password below:

Password: