A proposed more secure addition to Conky gmail scripts

Question

I use conky-cli for my status in DWM; furthermore, I use the gmail python script that has been floating around to check my emails (e.g. http://ubuntu-virginia.ubuntuforums.org … ?t=631157).  It had always bothered me that my password was just sitting there, so today I did something about that.  This method essentially replaces any instance where you are using wget.  It's a simple c script which uses libcurl.  Once compiled your password is not just there in plain text, and it's basically a drop in replacement for whatever wget command you are using.
#include <stdio.h>
#include <curl/curl.h>
int main(void)
CURL *curl;
CURLcode res;
curl=curl_easy_init();
if (curl)
curl_easy_setopt(curl, CURLOPT_URL, "https://USER:[email protected]/mail/feed/atom");
curl_easy_setopt(curl, CURLOPT_SSL_VERIFYPEER, 0L);
curl_easy_setopt(curl, CURLOPT_SSL_VERIFYHOST, 0L);
res=curl_easy_perform(curl);
curl_easy_cleanup(curl);
return 0;
Compile it with gcc and the -lcurl flag.
I don't know exactly how useful this is to anyone.  I am sure someone else has a better solution, but this was quick and easy for me.
Thanks.

Answer 1

measure wrote:Thank you for making the effort to create this; it is impressive.  The obvious question: is there any way around it?
It's not terribly impressive; I thought of using LD_PRELOAD to attack your program while reading the fakeroot man page, confirmed that the attack would work with:
su -c chmod go-r /usr/bin/id
fakeroot id
su -c chmod go+r /usr/bin/id
and then cranked out the easiest attack I could think of using LD_PRELOAD.
No, there is no way around this general class of attack.
measure wrote:The only fault I can see is that you had to know ahead of time I was using curl_easy_setopt to sneak in.  This of course isn't much of a fault, as a truly secure system should be public.  I know very little about C, but I would imagine there are ways around this.  Is there no way in C to make sure that I am using the curl_easy_setopt in curl/curl.h ?  If this can be done, then your exploit can be accounted for.
curl_easy_setopt is not 'in' curl/curl.h; curl/curl.h is a header file, and only contains the function prototype.  The actual code of curl_easy_setopt is in libcurl.so (roughly speaking; actually, libcurl.so itself is a symlink to a symlink to the shared library itself).
As for having to know you were using curl_easy_setopt: replacing that function was just the quickest attack I could code up, given that I had your program's source code.  As I mention in my README, a real attacker would go looking for a pre-prepared shared object and wrapper tool that would dump out all of the target program's code and data from the shared object's startup code (it's not hard; just dump the page containing the program's main function, then dump out the pages before and after that one until SIGSEGV happens).  I would be very surprised if such a tool isn't already widely available.
measure wrote:Either way though, thank you again for going out of your way to do this.  I really appreciate it.
I didn't notice the before-and-after times, but I think it took less than fifteen minutes to implement the attack after I saw the reference to LD_PRELOAD in the fakeroot documentation. 
measure wrote:As you seem to be a creative programmer, here's a challenge (which also somehow selfishly allows me to not learn any C, but get results...hmmm) which may or may not actually be a challenge: can I indeed get the desired information about the curl_easy_setopt I am using? Or any of the functions I use for that matter, I suppose I'd have to be more careful with all of them.  And suppose I could fix this, are there other ways to exploit it?
By 'the desired information about the curl_easy_setopt [you are] using', I assume you mean 'which library's curl_easy_setopt am I using?'.  The answer is no, and the glibc dynamic linker goes to some trouble to keep you from finding that out.  Even if you could, some code in the shared object would run before your program's main function, and that could easily dump out the sensitive areas of your address space.
measure wrote:I ask this not because I think someone wants to steal my email address.  This is of course just out of curiosity at this point; but I appreciate your enthusiasm none-the-less.
The best solution is writing a daemon, and feeding it your password at startup through a pipe.  I don't think you'll be able to do that yourself at the moment; little things like error handling become both more important and trickier to implement properly.
Making your program setuid would keep LD_PRELOAD attacks like mine from working (because ld.so can detect that a program is setuid, and takes some precautions to block the obvious privilege escalation holes), but I don't know whether libcurl has a similar 'feature'.  (If you must do this, make its owner a special account that is not used for any other purpose; do *not* use the 'nobody' account for this program.)