A proposed more secure addition to Conky gmail scripts

measure · 2010-05-20 05:27:49

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:PASSWORD@mail.google.com/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.

rebugger · 2010-05-20 05:54:40

it will just need a little bit more effort to extract your password from the binary (tried a hexeditor? deassemble, ...)
So this is not a real solution, i guess.

measure · 2010-05-20 06:49:06

Well certainly it is not secure, it is simply "more" secure. The point is the password is not sitting in plain text. If you're going to have a password read by something, then there is absolutely no way to 100% encrypt it, as then it cannot be read. Does this mean it is pointless to slide it under the rug a bit? Maybe even mat it down so it's more distributed instead of one big lump? As I said, I just didn't like some file that clearly had password="PASSWORD" in broad daylight.

You can't please everyone! or anyone I suppose, if you're me.

measure · 2010-05-25 18:46:28

rebugger:

Regarding your concern, I have a question as I am generally unknowledgeable of these things: do you need read permissions to deassemble? As of right now only the root user has read/write permissions on the file. I.e., users can only execute the file, but not read it. For clarity, the file has 711 permissions. Can it still be deassembled? Obviously it cannot be read by the hex-editors.

Thanks,
Ryan

Last edited by measure (2010-05-25 18:47:35)

rransom · 2010-05-28 05:40:14

w00t! http://github.com/rransom/why-mode-0711-is-not-enough

measure · 2010-05-28 07:47:06

rransom,

Thank you for making the effort to create this; it is impressive. The obvious question: is there any way around it?

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.

Either way though, thank you again for going out of your way to do this. I really appreciate it.

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?

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.

Thanks,
Ryan

rransom · 2010-05-28 08:26:30

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.)

mikesd · 2010-05-28 09:18:36

rebugger wrote:

it will just need a little bit more effort to extract your password from the binary (tried a hexeditor? deassemble, ...)
So this is not a real solution, i guess.

[mike@mercury|~] $ gcc test.c -lcurl -o test
[mike@mercury|~] $ strings -n 32 test 
https://USER:PASSWORD@mail.google.com/mail/feed/atom

This is no different to having the password in plaintext. Nice try though.

siu4coders · 2010-05-28 10:01:20

Hi all,

Google now accepts user authentication with oauth, maybe you can give it a try:
http://code.google.com/apis/gmail/docs/#inbox
http://code.google.com/apis/gdata/docs/ … html#OAuth
http://code.google.com/apis/accounts/do … arted.html

I found this python oauth authentication library: http://github.com/simplegeo/python-oauth2

Has anyone implemented a conky script with these tools?

measure · 2010-05-28 18:38:51

mikesd wrote:

This is no different to having the password in plaintext. Nice try though.

mikesd,

As the file has 711 permissions, this method does not work. `strings` needs to read the file. rransom's thoughtful exploit is the problem, not your suggestion.

siu4coders,

Thank you for this information; I will look into it.

Thanks,
Ryan

rransom · 2010-05-28 20:22:09

http://code.google.com/apis/gdata/docs/ … lientLogin is more appropriate than OAuth.

EDIT: OOPS, this authentication method won't work for the GMail inbox feed.

Last edited by rransom (2010-05-28 20:23:46)

Arch Linux

#1 2010-05-20 05:27:49

A proposed more secure addition to Conky gmail scripts

#2 2010-05-20 05:54:40

Re: A proposed more secure addition to Conky gmail scripts

#3 2010-05-20 06:49:06

Re: A proposed more secure addition to Conky gmail scripts

#4 2010-05-25 18:46:28

Re: A proposed more secure addition to Conky gmail scripts

#5 2010-05-28 05:40:14

Re: A proposed more secure addition to Conky gmail scripts

#6 2010-05-28 07:47:06

Re: A proposed more secure addition to Conky gmail scripts

#7 2010-05-28 08:26:30

Re: A proposed more secure addition to Conky gmail scripts

#8 2010-05-28 09:18:36

Re: A proposed more secure addition to Conky gmail scripts

#9 2010-05-28 10:01:20

Re: A proposed more secure addition to Conky gmail scripts

#10 2010-05-28 18:38:51

Re: A proposed more secure addition to Conky gmail scripts

#11 2010-05-28 20:22:09

Re: A proposed more secure addition to Conky gmail scripts

Board footer