Welcome to LinuxQuestions.org, a friendly and active Linux Community. You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features.

Registration is quick, simple and absolutely free. Note that registered members see fewer ads, and ContentLink is completely disabled once you log in. Nik Hdr Efex Pro Torrent.

Are you new to LinuxQuestions.org? Visit the following links: If you have any problems with the registration process or your account login, please. If you need to reset your password,. Having a problem logging in?

Please visit to clear all LQ-related cookies. Introduction to Linux - A Hands on Guide This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter. For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own. To receive this Complete Guide absolutely free.

Source: Metamail has been reported prone to multiple vulnerabilities that may provide for arbitrary code execution.

I fetch mail with fetchmail and read it with mailx. If someone sends an attachment I have to use metamail. If an attachment is made one way rather than another (I haven't figured out the difference) metamail only asks me if I want to view it with the app associated with the file's type, not give me a chance to save them to a file. To do that I have to edit the message, separate the attachments into their own files, then un-mime them with mimencode, which is a drag. I want an alternative to metamail that will extract them all to separate files. /bin/bash if [ $1 ] then if [ -s $1 ] then boundary=`grep boundary= $1 cut -d ' -f2` if [ $boundary ] then for attachment in `grep 'Content-Disposition: attachment;' $1 cut -d ' -f2` do if!

[ $attachment ] then echo -n 'Attachment unnamed: what do you want to call it? ' read attachment fi if [ $attachment ] then sed -n /'Content-Disposition: attachment; filename= '$attachment '/,/$boundary/p $1 grep -Ev boundary= 'Content-Disposition: attachment;' mimencode -u -o $attachment else echo no attachment name fi done else echo no boundary fi else echo $1 does not exist fi else echo Specify a message file to extract attachments from fi.

Date: Sun, 12 Feb 2006 10:34:54 +0100 [ (text/plain, inline)] Subject: metamail: crashes with very long boundaries in messages Package: metamail Dance House Vol 1 Nexus Manager there. Version: 2.7-50 Severity: important Tags: patch Hello, I have found that metamail crashes when processing messages with very long boundaries. They cause a buffer overflow, which doesn't seem to be exploitable: metaur@metaur:~$ /usr/bin/metamail To: Subject: metamail crash bug *** glibc detected *** free(): invalid next size (normal): 0x0805fc30 *** Aborted metaur@metaur:~$ I have attached a test message, as well as a patch. Date: Sun, 12 Feb 2006 11:20:05 -0500 tag 352482 security thanks On Sun, Feb 12, 2006 at 10:34:54AM +0100, Ulf Harnhammar wrote: >Subject: metamail: crashes with very long boundaries in messages >Package: metamail >Version: 2.7-50 BTW, what is in./metamail, rather than./src/metamail/?? Is it a different source version?? It has, instead, on line 447: LineBuf = malloc(LINE_BUF_SIZE); if (!LineBuf) ExitWithError(nomem); sprintf(LineBuf, '--%s', boundary); >I have found that metamail crashes when processing messages with >very long boundaries.

They cause a buffer overflow, which doesn't >seem to be exploitable: How is this not [potentially] exploitable? Date: Mon, 13 Feb 2006 12:45:46 +0100 >BTW, what is in./metamail, rather than./src/metamail/?? I don't know.

I noticed that the source is included twice, but I haven't looked into why that is the case. FWIW, if you just patch the source in src and not in., the resulting binaries seem to be fixed.