## Interview with an Adware Author

A place to discuss the implementation and style of computer programs.

Moderators: phlip, Moderators General, Prelates

Fume Troll
Posts: 254
Joined: Wed Jan 13, 2010 8:06 am UTC
Location: Scotland / Norway mainly

### Interview with an Adware Author

A bit old, but I couldn't find it discussed here.

I found this very interesting, from both a technical and ethical point of view, and thought others might be interested.

http://philosecurity.org/2009/01/12/int ... are-author

scarecrovv
It's pronounced 'double u'
Posts: 674
Joined: Wed Jul 30, 2008 4:09 pm UTC
Location: California

### Re: Interview with an Adware Author

That's pretty fascinating. I was particularly horrified by the Create Remote Thread capability. What genius at Microsoft thought that would be a good idea?

Posts: 3072
Joined: Mon Oct 22, 2007 5:28 pm UTC
Location: Beaming you up

### Re: Interview with an Adware Author

Yet another IE horror story, and kinda funny that he got roped into adware authoring by first getting a job removing it.
<quintopia> You're not crazy. you're the goddamn headprogrammingspock!
<Cheese> I love you

Goplat
Posts: 490
Joined: Sun Mar 04, 2007 11:41 pm UTC

### Re: Interview with an Adware Author

scarecrovv wrote:That's pretty fascinating. I was particularly horrified by the Create Remote Thread capability. What genius at Microsoft thought that would be a good idea?

I'm pretty sure you can do it on Linux too using ptrace.

scarecrovv
It's pronounced 'double u'
Posts: 674
Joined: Wed Jul 30, 2008 4:09 pm UTC
Location: California

### Re: Interview with an Adware Author

Goplat wrote:
scarecrovv wrote:That's pretty fascinating. I was particularly horrified by the Create Remote Thread capability. What genius at Microsoft thought that would be a good idea?

I'm pretty sure you can do it on Linux too using ptrace.

Well gee, what FOSS genius thought that was a good idea?

Seriously though, why does this functionality exist?

phlip
Restorer of Worlds
Posts: 7573
Joined: Sat Sep 23, 2006 3:56 am UTC
Location: Australia
Contact:

### Re: Interview with an Adware Author

For debugging purposes, for one... Attach a debugger (or a program which claims to be a debugger) to a process and you can raise hell... regardless of what the mechanism is.

Code: Select all

enum ಠ_ಠ {°□°╰=1, °Д°╰, ಠ益ಠ╰};void ┻━┻︵​╰(ಠ_ಠ ⚠) {exit((int)⚠);}
[he/him/his]

scarecrovv
It's pronounced 'double u'
Posts: 674
Joined: Wed Jul 30, 2008 4:09 pm UTC
Location: California

### Re: Interview with an Adware Author

phlip wrote:For debugging purposes, for one... Attach a debugger (or a program which claims to be a debugger) to a process and you can raise hell... regardless of what the mechanism is.

Interesting. It doesn't seem like that ought to be permitted except in special circumstances. Something like a special compilation flag to allow it.

Dr. Willpower
Posts: 197
Joined: Wed May 28, 2008 3:55 pm UTC

### Re: Interview with an Adware Author

scarecrovv wrote:
phlip wrote:For debugging purposes, for one... Attach a debugger (or a program which claims to be a debugger) to a process and you can raise hell... regardless of what the mechanism is.

Interesting. It doesn't seem like that ought to be permitted except in special circumstances. Something like a special compilation flag to allow it.

Then you have the problem of either Windows deciding which programs you're allowed to debug with, or hackers compiling with the flag on when they need to use the functionality.

Hat me, bro

Posts: 3072
Joined: Mon Oct 22, 2007 5:28 pm UTC
Location: Beaming you up

### Re: Interview with an Adware Author

At least then though, there is a noticeable difference between debuggable and non-debuggable code. It isn't hard to warn when someone downloads or runs a debug build, and most end users should never be running those anyway.
<quintopia> You're not crazy. you're the goddamn headprogrammingspock!
<Cheese> I love you

Axidos
Posts: 167
Joined: Tue Jan 20, 2009 12:02 pm UTC
Location: trapped in a profile factory please send help

### Re: Interview with an Adware Author

Dr. Willpower wrote:
scarecrovv wrote:Interesting. It doesn't seem like that ought to be permitted except in special circumstances. Something like a special compilation flag to allow it.

Then you have the problem of either Windows deciding which programs you're allowed to debug with, or hackers compiling with the flag on when they need to use the functionality.

I thought Scarecrovv was talking about the 3rd party program having the flag (though I'm sure there'd be some way to remove it). You seem to be responding as if he's talking about the hacker's program which I doubt: there's no sense in letting the hacker choose whether or not he wants to hack.

Dr. Willpower
Posts: 197
Joined: Wed May 28, 2008 3:55 pm UTC

### Re: Interview with an Adware Author

Axidos wrote:
Dr. Willpower wrote:
scarecrovv wrote:Interesting. It doesn't seem like that ought to be permitted except in special circumstances. Something like a special compilation flag to allow it.

Then you have the problem of either Windows deciding which programs you're allowed to debug with, or hackers compiling with the flag on when they need to use the functionality.

I thought Scarecrovv was talking about the 3rd party program having the flag (though I'm sure there'd be some way to remove it). You seem to be responding as if he's talking about the hacker's program which I doubt: there's no sense in letting the hacker choose whether or not he wants to hack.

Oooh, ooh, oh. I understand. I was under the impression that he meant.. something else.

Hat me, bro

TNorthover
Posts: 191
Joined: Wed May 06, 2009 7:11 am UTC
Location: Cambridge, UK

### Re: Interview with an Adware Author

Still, from the other end I want to be able to debug any process on my system without the original compiler's permission. Perhaps a "debug me" flag that's immutable after process-creation could work.

Goplat
Posts: 490
Joined: Sun Mar 04, 2007 11:41 pm UTC

### Re: Interview with an Adware Author

If you want process X to be protected against meddling by other processes running with uid A, just don't run process X as uid A. No funky compile flags necessary, works on both Windows and *nix.

Likpok
Posts: 471
Joined: Tue Feb 20, 2007 6:21 am UTC
Location: :noitacoL
Contact:

### Re: Interview with an Adware Author

Most of the adware information appears to be pre-Vista. From what the security people I know say, post-Vista is a whole different beast in terms of attack vectors.

On the note of CreateRemoteThreadEx, it seems that you need specific rights to successfully execute it. I do not know what the default policy is, but I would imagine it would prevent this.

Also note that these things may require installation. If they do, there isn't really an exploit. Remember: doing nasty things as root isn't a security hole, but a feature.
There's an art to cooking toast
Never try to guess
Cook it till it's smoking
Then twenty seconds less.

Sc4Freak
Posts: 673
Joined: Thu Jul 12, 2007 4:50 am UTC
Location: Redmond, Washington

### Re: Interview with an Adware Author

scarecrovv wrote:That's pretty fascinating. I was particularly horrified by the Create Remote Thread capability. What genius at Microsoft thought that would be a good idea?

Because it doesn't affect the security of the system - it should be obvious that CreateRemoteThread can only be used if you have the necessary rights/permissions to do so.

On Windows, functions like CreateRemoteThread, WriteProcessMemory, TerminateProcess and other such functions require strict access rights. If your process doesn't have these access rights, then the OS won't let you do it.

If you do have full rights, then functions like CreateRemoteThread serve a necessary purpose as they provide a documented method to perform some action (in this case, creating a thread that runs in another process). Let's say for example that I have full access rights to the entire system, and I want to create a thread in a remote process. I can do it two ways: I can call CreateRemoteThread, or I can rely on undocumented behaviour and find a way to hack the remote process to run my code. That means that even if a documented function to do something doesn't exist, it doesn't stop anyone from doing it via undocumented hacks. Obviously, you'd prefer that people used the documented functions.

If I didn't have the access rights in the first place, then I can't do anything - CreateRemoteThread or not. Functions like CreateRemoteThread just provide a documented way of doing these things - it doesn't affect security at all.

Osha
Posts: 727
Joined: Wed Dec 03, 2008 3:24 am UTC
Location: Boise, Idaho, USA

### Re: Interview with an Adware Author

I like the part where he mentions adware under WINE on linux.
I've had that happen before, I installed some asteroids clone (eGames you scoundrel!) and a few minutes later up popped pop-up boxes!
'Course they never came back after killing all the wine processes.

0rm
Posts: 81
Joined: Wed Feb 17, 2010 2:30 pm UTC

### Re: Interview with an Adware Author

Ahhhhhhhhhhhhhh good ol' wineserv -k
They say it's unhackable; I think it can be hacked.
They say it's fast; I think it could be faster.
They say it's the best; I think it can be done better.

userxp
Posts: 436
Joined: Thu Jul 09, 2009 12:40 pm UTC

### Re: Interview with an Adware Author

What I am horrified by is that in order to run a program that consists of "show this animation until the mouse is moved" (a screensaver) you actually let it do whatever it wants to your computer, like erasing files, transmitting private data or modifying system executables.

And also that most programs insist to being copied to an arbitrary location (C:\Program files\) and storing all their data in another place (the registry) mixed with data from other applications, instead of running from wherever they are and saving their data with them.

Sc4Freak
Posts: 673
Joined: Thu Jul 12, 2007 4:50 am UTC
Location: Redmond, Washington

### Re: Interview with an Adware Author

userxp wrote:What I am horrified by is that in order to run a program that consists of "show this animation until the mouse is moved" (a screensaver) you actually let it do whatever it wants to your computer, like erasing files, transmitting private data or modifying system executables.

A screensaver is a program like any other. If you voluntarily loaded a malicious program onto your computer, there's a limit to what the OS can do to protect you. Some things (like modifying system files) require administrative privileges (eg. root access on Linux, UAC on Windows, etc.), but that's about it. I'm surprised that you're also not horrified that a program that consists of "allowing you to enter text" (a text editor) also is allowed to transmit private data and erase files.

And also that most programs insist to being copied to an arbitrary location (C:\Program files\) and storing all their data in another place (the registry) mixed with data from other applications, instead of running from wherever they are and saving their data with them.

Because that's actually a very bad idea. In Windows, Program Files is a protected location. Users and applications wanting access to Program Files require administrator access via UAC prompt, which means that actual application executables are protected from modification (accidental or malicious) by the OS. If you want to save data to the same place your application is running from, then you'd need a UAC prompt to give write access to Program Files.

The fact that so many poorly written programs did this is why Vista included a compatibility feature called the VirtualStore - if your application tries to write to its own folder in Program Files, the OS will transparently redirect the file operations to a different, "virtual" Program Files folder that doesn't have the same security restrictions as the real thing. So when applications read/write their user data to/from their application folder in Program Files, the OS transparently redirects the file operations out to the less secure virtual store, while keeping the actual applications inside the real, secure, Program Files folder.

When storing user data or user settings, the preferred method is to use the "Application Data" special folder path. On Vista and above, this is located in C:\Users\USERNAME\AppData. You shouldn't be storing user settings in the registry or Program Files - Windows programming guidelines are that you should prefer AppData.

Storing user settings in the proper AppData location guarantees 3 things:
1. Security of Program Files folder is not breached
2. The user can choose to keep application settings, even when uninstalling an application
3. Different users on the same system can have different settings for the same application (transparent to the application)

Considering all of the above, what could possibly be the benefit of making all applications "portable"?

Goplat
Posts: 490
Joined: Sun Mar 04, 2007 11:41 pm UTC

### Re: Interview with an Adware Author

userxp wrote:What I am horrified by is that in order to run a program that consists of "show this animation until the mouse is moved" (a screensaver) you actually let it do whatever it wants to your computer, like erasing files, transmitting private data or modifying system executables.

Agree 100%! Whoever designed Windows NT apparently still had the Unix mentality, of a "computer" being a room-sized behemoth, with a highly-paid professional administrator who installs all the software, and thousands of users. The administrator doesn't install malicious software, because knowing better is his job. Security is all about protecting the computer against a malicious user.

For personal computers, this security model is an utter disaster. The sole user isn't malicious, just clueless; unfortunately he is also the administrator. Instead of investigating the veracity of everything (including reading BugTraq constantly to ensure that a good program doesn't become a bad one via a security flaw!) and/or creating restricted user accounts to sandbox things in (and most Windows programs come in opaque installers that demand that you elevate them to Administrator privileges, making this even harder!), most people just take the path of least resistance and run random software unsandboxed. FAIL.

Sc4Freak wrote:A screensaver is a program like any other. If you voluntarily loaded a malicious program onto your computer, there's a limit to what the OS can do to protect you. Some things (like modifying system files) require administrative privileges (eg. root access on Linux, UAC on Windows, etc.), but that's about it. I'm surprised that you're also not horrified that a program that consists of "allowing you to enter text" (a text editor) also is allowed to transmit private data and erase files.
That's how things are now, but couldn't we do better?

Someone needs to make a sane personal computer OS. I've thought a little bit about what that might be like:
• Basic sandboxing of every program done automatically, so that a program starts out with access only to those files associated with itself in some way. So for example, maybe \foo.exe can access \foo\*, but not \bar\* or \privatestuff\foo\* or \firefox\profile1\signons.sqlite.
• Programs can read, write, or create outside files by explicit permission of the user, mediated by the shell. When I save my work from foo.exe, it first requests the shell to open a "save file" dialog box; I choose to save the document as \documents\blah.foo, and the shell grants foo.exe permission to access \documents\blah.foo.
• Modications to privileged code such as the kernel or shell would be a very user-unfriendly process. It needs to really set off red flags in the user's head compared to setting up ordinary programs.

Xanthir
My HERO!!!
Posts: 5426
Joined: Tue Feb 20, 2007 12:49 am UTC
Contact:

### Re: Interview with an Adware Author

Goplat wrote:Someone needs to make a sane personal computer OS. I've thought a little bit about what that might be like:
Basic sandboxing of every program done automatically, so that a program starts out with access only to those files associated with itself in some way. So for example, maybe \foo.exe can access \foo\*, but not \bar\* or \privatestuff\foo\* or \firefox\profile1\signons.sqlite.
Programs can read, write, or create outside files by explicit permission of the user, mediated by the shell. When I save my work from foo.exe, it first requests the shell to open a "save file" dialog box; I choose to save the document as \documents\blah.foo, and the shell grants foo.exe permission to access \documents\blah.foo.
Modications to privileged code such as the kernel or shell would be a very user-unfriendly process. It needs to really set off red flags in the user's head compared to setting up ordinary programs.

This is essentially the web security model being hashed out with the FileReader, FileSystem, etc. js apis.
(defun fibs (n &optional (a 1) (b 1)) (take n (unfold '+ a b)))

userxp
Posts: 436
Joined: Thu Jul 09, 2009 12:40 pm UTC

### Re: Interview with an Adware Author

Sc4Freak wrote:Storing user settings in the proper AppData location guarantees 3 things:
1. Security of Program Files folder is not breached
2. The user can choose to keep application settings, even when uninstalling an application
3. Different users on the same system can have different settings for the same application (transparent to the application)

Considering all of the above, what could possibly be the benefit of making all applications "portable"?

Just to clarify, here is how I think computer applications should work:
1. Applications should be distributed as a single file containing all the data that will be used by the program. There should be no difference between running a program from the hard disk or from a flash drive.
2. When starting such an application, the OS should start the program in a sandbox. Any interaction with the outside world should be handled by the OS and only be allowed if considered secure (file access should be granted by the user).
3. Application settings should be stored in a separate file in the same location as the application file.
There is no necessity for a Program Files folder.
The advantages? If you want to try the new Firefox 5.0, you download firefox5.app to your flash drive, double click, and use it for a while. If you like it you can run it in any computer as easy as in yours, and if you don't like it you just erase firefox5.app and firefox5.appdata.

If you don't think this is a good idea, then I dare you to visit any freeware page and install 50 different untrusted programs in your computer. And disable your anti-virus first .

BobTheElder
Posts: 86
Joined: Wed Feb 17, 2010 11:30 pm UTC
Location: England, near Bournemouth

### Re: Interview with an Adware Author

userxp wrote:If you don't think this is a good idea, then I dare you to visit any freeware page and install 50 different untrusted programs in your computer. And disable your anti-virus first .

i bet the screensavers site is pretty safe, at least!
Rawr

Posts: 3072
Joined: Mon Oct 22, 2007 5:28 pm UTC
Location: Beaming you up

### Re: Interview with an Adware Author

No, screensavers are just executables wrapped inside an .SCR file. It used to be a really popular vector for viruses. Not sure how much it is used now though.
<quintopia> You're not crazy. you're the goddamn headprogrammingspock!
<Cheese> I love you

BobTheElder
Posts: 86
Joined: Wed Feb 17, 2010 11:30 pm UTC
Location: England, near Bournemouth

### Re: Interview with an Adware Author

headprogrammingczar wrote:No, screensavers are just executables wrapped inside an .SCR file. It used to be a really popular vector for viruses. Not sure how much it is used now though.

I didn't know the specifics, but I did know that 'download these free screensavers!' = 'get a virus!'- shoulda used the <sarcasm> tag :p
Rawr

'; DROP DATABASE;--
Posts: 3284
Joined: Thu Nov 22, 2007 9:38 am UTC
Location: Midwest Alberta, where it's STILL snowy
Contact:

### Re: Interview with an Adware Author

Goplat wrote:Someone needs to make a sane personal computer OS. I've thought a little bit about what that might be like:
• Basic sandboxing of every program done automatically, so that a program starts out with access only to those files associated with itself in some way. So for example, maybe \foo.exe can access \foo\*, but not \bar\* or \privatestuff\foo\* or \firefox\profile1\signons.sqlite.
• Programs can read, write, or create outside files by explicit permission of the user, mediated by the shell. When I save my work from foo.exe, it first requests the shell to open a "save file" dialog box; I choose to save the document as \documents\blah.foo, and the shell grants foo.exe permission to access \documents\blah.foo.
• Modications to privileged code such as the kernel or shell would be a very user-unfriendly process. It needs to really set off red flags in the user's head compared to setting up ordinary programs.
In other words, SELinux.
poxic wrote:You suck. And simultaneously rock. I think you've invented a new state of being.

### Who is online

Users browsing this forum: No registered users and 8 guests