Ok added to the todo list

You don't filter out CPP macro's. I would skip that and only allow C code. Or run this thing in a proper jail because at the moment:

- doing an include #include "/dev/random" will block the thread. - including "/etc/passwd" is also possible although I don't see a direct way to turn this into password disclosure.

Seriously; even if it's a weekend project, letting people run all kinds of potentially bad code on your machine is never a good idea. Even though you don't run the binaries yourself there's so many ways to mess around with a compiler. You just don't know what's going to happen.

chroot would probably be sufficient. Barring some sort of code execution vuln in the compiler you can only load stuff off of the filesystem.

Having the actual CPP available is nice because some bits of libc are only macros.

I have now added some basic macro detection

#define x "/etc/passwd" #include x

I have now fixed it. But I think there must be an other way to make it safe. Maybe a sandbox

If it's a server used for other things, definitely a sandbox. gcc's not exactly security hardend. Best one (novel solution, though the code's old and shit) I've come across: https://pts-mini-gpl.googlecode.com/svn/trunk/uevalrun/doc/u...

This is part of your /etc/shadow file:

    root:censored

We can still read /etc/ssh/ssh_host_rsa_key, etc.

Edit: removed hash, sorry

Saying "you can read /etc/shadow by doing X, Y, and Z" is okay -- it's a permanent record there was a flaw. Saying "here's your root password hash" is not ok; even once the flaw is fixed, that hash is still floating around out there. I'd take advantage of the edit period and remove that from your comment; it's just not cool. The OP should definitely change the root password on the box regardless.

Well one easy way to increase security would for this to stop running as root.

Please, don't ever run your application code as root. Less so when it's facing the Internet.

No problem I think I could fix it.

Can you show us how you read the content of the file. Just want to learn more

I have now used a the wrapper by gcc-explorer https://github.com/mattgodbolt/gcc-explorer/blob/master/c-pr...

From my point of view doing it manually is still the best option. Because know what and how you are implementing the design, this will save you a lot of energy fixing or debugging things. I personally just use PHPStorm to edit and manage my files.

I make a little over 600$ selling a Newsletter script on Codecanyon http://codecanyon.net/item/newsletter-mailer-v13/149365

Currently I am planing a SaaS Newsletter Mailer.

I use your script. It's very nice and worth the price, but the script setup is more complicated than it needs to be and the smtp is broken and I'm forced to use phpmailer. Two things I've never had issues with from all the other scripts I've installed on my server over the past 7 years.

I'd still prefer it over SaaS Mail because I don't have re-occuring costs every month and I like being in control of my own email lists and the iframe embedded email newsletter signup is awesome. I wouldn't have it any other way.

I'm the one that asked you about how to check the database to see if a user had already signed up for a specific category newsletter before adding them to it again. That's another thing you should fix.

3 little flaws but the rest of the script is just sooooo perfect. It's sold over 1800+ times because designers/developers like us HATE SaaS newsletter mailers. We like your script.

The problem with running your own mail script is your inboxing rate. Your IP is not going to be white listed and it can really hurt you later on. Not to hate on the OP, but if you are building a serious business that needs to ensure deliverability of email to users, I recommend an outside provider like SendGrid, SailThru, MailGun, MailChimp, iContact, etc...

The software also supports Amazon SES

MailChimp?

Great Book