Safer-Networking Forums - Blogs - PepiMK

Facebook on iPhone privacy

PepiMK — Mon, 17 May 2010 10:56:27 GMT

I recently installed Facebook on my iPhone, and now it sends me the usual Facebook events about new comments, status updates, wall posts, etc... except it does not send them for my account, but for someone else's.

I tried to find out whose privacy Facebook is violating by sending me his or her messages, but couldn't so far.

I also couldn't find an email address to contact at Facebook about this, and didn't want to register in one of their many places that still do not exactly fit into this category. Maybe someone from Facebook can contact me when reading this, otherwise we'll have to deal with the iPhone Facebook application as spyware, since it spies on someone else for me even though I don't want it.

Spybot 2.0: Scripting

PepiMK — Fri, 14 Aug 2009 10:00:21 GMT

The complexity of malware is causing new challenges for anti malware software every day. Randomized malware that has thousands of new variants out calls for loose heuristics, detection patterns need to be slightly adjusted all the time, and new technologies call for new methods of reaction.

The standard approach to store malware detection patterns has been databases for decades. We've been using databases ourselves for the past ten years, with just slight adjustments (like subfunctions, jump instructions and variables) to boost the performance.

While speaking about the evergrowing challenges, our team has come up with another idea - we reached the point where we decided that it would be a waste of time to add more and more features of a programming language, but, due to the database restriction, with assembly-like comfort only. So we went ahead and tried to opt for a high level language right away, adding all the comfort a codewriter is used too at once. Making it easier to avoid false positives by having much more control over heuristics in various situations.

On a very basic level, this is not unlike OpenSBI. Imagine the following OpenSBI command:

Code:

File:"<$FILE_EXE>","<$WINDIR>\malwar*.exe","filesize=4711"

You can do the same in SpybotScript in a very similar way:

Code:

sbiFile('<$FILE_EXE>', '<$WINDIR>\malwar*.exe', 'filesize=4711');

Do you recognize the language? Its Pascal (nowadays knows as Delphi mostly). And next to the simple conversion, it offers all the standard contructs of Delphi (like if...then, repeat...until, while...do, case...of and more), plus many useful functions for dealing with files and the registry directly (where the commands above would simply add items to the scan results):

Code:

var sFilename: string;
begin
   if sbiWindowsIsNTBased then begin
      sFilename := GetSystemServiceFilename('MalwareService');
      StopSystemService('MalwareService');
      sbiFile('<$FILE_EXE>', sFilename, '');
   end;
end.

This one might be a bit simple, since the cleaner might already be able to kill a system service, but it gives a first glimpse at the possibilities.

So where will we see this in action exactly? Well, in the first place, scripts will be enhancements to the main scanner, since the purpose is to aid in detecting thing. In the long run, as standalone fixes for threats maybe? The options available now are nearly endless.

Spybot 2.0: cleaning concepts

PepiMK — Sun, 21 Dec 2008 22:55:58 GMT

With the rising of rootkits and professional malware, cleaning those away got more and more important and should earn a more prominent position next to scanning.

The cleaning concept in Spybot-S&D 1.x is already doing a lot, like for example trying more than a dozen methods to get rid of files. It's a bit one-dimensional though, and one of its worst disadvantages is the need to do sometimes do a complete rescan on boot to cleanup some files. Cleaning in Spybot 2.0 will therefore be separated into multiple stages, of which only the necessary ones will be performed of course:

Direct Cleaning (stage 1): right after an on-demand scan, you will be able to remove malware much as you're already used to. Items that cannot be removed because they're in use by sensitive parts of the Operating System and cannot even be unloaded are queued for removal after a reboot.
Elevated Cleaning (stage 2): the first new part is that if you are not an administrator, or, on Vista, have scanned without elevating, Spybot will offer you to elevate or log in as administrator and continue cleaning with full privileges and without the need to rescan. This separate cleaner module will to clean up the results of your last scan at any given time, for example at boot time.
After Login Cleaning (stage 5): an attempt at removing files through the "old" methods of running removal after login still exists, though no longer using the command interpreter, but our dedicated cleaner, making it more transparent what has been done. This is still necessary to deal with stuff that is not available in stage 3 or 4, e.g. user specific registry entries.
Before Login Cleaning (stage 4): malware sometimes loads even before the user logs in, and since removing malware should take place before malware loads, this is a place where we've put another, silent stage of the cleaning process. Whenever there are unprocessed scan results still open, another attempt of removal takes place here.
Early Reboot Cleaning (stage 3): what is the earliest place one could start removing malware? You might have noticed Microsofts disk checking takes places while Windows still loads - simple text on a blue or black background. This is not the Windows you know at all, but the pure Operating System. For really heavy cases, we start here removing malware.
In case you wonder if this does not make stage 4 surplus: for performance reasons, this stage does contain only the most important cleaning routines.

Again, this all should happen with the goal that things should get easier than more complicated for the user, which for example is one reason why stage 4 happens silently and the confusing short flashing of the command prompt in the predecessor of stage 5 needed to be gone.

Spybot 2.0: the scan method

PepiMK — Tue, 09 Dec 2008 11:06:39 GMT

I've read it mentioned as a request for 2.0, and it's been a controversial thing for a long time, so I thought this earns its own 2.0 blog entry.

The standard AV (antivirus) approach at scanning is filesystem based, iterating through all or selected file partitions or folders. Extend that to AS (antispyware), and you'll add a full registry iteration as well. Each file/registry entry will be compared to a set of detection rules.

Our "current" (1.x) approach is mostly pattern-based, iterating though a list of definitions and trying to find malware that way. It's actually quite a bit more complex than that, but I'll leave it there for the introduction.

Going back in time, the reason we chose the pattern based access is clear. A few dozen of threats existed somewhere around the year 2000, simple software with clear schemes to detect. A pattern based detection meant a very fast scanning time. A downside of this is that what is often called "inactive" malware does not got detected this way - if you copy malware files to a different location for example. Different locations are not a problem with active malware, since if the malware changes its behaviour where to install itself, detection patterns need an update anyway (changed files mean different hashes). Well, it soon got more a bit more sophisticated than that.

About 4 years ago, we already had a 2.0 hybrid filesystem/registry based scanner combied with a few optimization features from our pattern based scanner ready, but there we met a big disadvantage of those. If you take a look at the OpenSBI wiki, you'll notice that we are able to link various detection patterns together, e.g. using the name of a detected file to flag an associated registry entry, and vice versa. If you scan both registry and filesystem at the same time, one would all the time have to wait for "final" results from the other, creating a deadlock situation. Regular filesystem/registry iteration scanners are not capable of using result parts in other patterns because the order in which events do appear is undefined.

Another downside of filesystem scanners is relative as to when problems are fixed. We often encounter malware that uses various small stubs to re-install themselves. On a pure on-demand scan and with partial fixing appearing the moment a problem is encountered, a pattern iterating scanner is able to scan and fix problems that belong together in as shorter timespan, reducing the chance that the re-installation cycle of the malware has time to complete before it has been completetely removed.

Third, the time a scan takes is essential. Users already now complaint about a scan that takes "an hour". A filesystem/registry iterating scanner would, similar to AVs, take multiple hours, and most users probably would not accept such a timespan. The best method to counter this obviously would be realtime on-access protection, which would make regular full on-demand scans less necessary (still very much needed after an infection/when cleaning from a bootable PE CD for example). The big problem with on-access scanning are AV companies of course, which already now, while we still have a near-access scanner designed especially to not conflict take the on-access scanning as a reason to force users to uninstall our product. Switching to a system that depends on a filesystem/registry based scan iterator therefore in the current situation would mean product suicid for us really. A "nice" (for them) illegal way of improper competition by the mentioned AVs to keep competition like us down; something which we're not going to tolerate for much longer, so don't take this is any indicator of what might or might not appear in a final 2.0.

Well, this blog entry already has reached some length just discussing the theories of the two approaches, so I'll save going into how we're working at hybrid modes for another post.

A few things about reporting bugs

PepiMK — Mon, 01 Dec 2008 11:32:54 GMT

No direct 2.0 blog post this week, the next one will be discussing the differences between various scanner models, a topic I need more time to write about since its far from easy. Instead, an older entry I had saved as a draft but never published so far, and looking for an excuse to use it in the 2.0 blog posts line, which is kind of important at least for error reporting on the 2.0 beta ;)

---

Many might have noticed that I set a high value on proper bug reporting, but what exactly is it that I tend to see as proper? Are these universal standards or personal approaches? I decided to blog a few guidelines and my own opinion on them including some reasoning.

1. Versions. If you report an older version, whoever is going to help can first look up the history of changes since that version. Reporting the used version might make it unnecesary to even try to reproduce a bug, saving a lot of time for the developer/supporter, which in the end is to your benefit as well, since you'll get a faster answer. That's universal imho, a detail that belongs into every bug report.

2. Experienced vs. Expected. This might sound obvious, too, but this actually forces the reporter to think a bit more. Reports like "My X stopped working" are highly unlikely if you adhere to this requisite, since everyone would immediately notice that the "Expected" answer "I want it to be working" does not sound like a useful report. Complaining that a product does only support IE does not really help improve the situation, expressing the expectation that it supports HyperBrowser 11.7, but you could not see it listed as supported, does. Since I like maths, it really comes down to these two lines:

Bug/Error/Feature Request = Expectation - Experience
and
Report = Situation + Bug/Error/Feature Request

You'll notice that I try to enforce this for every single report on our bugtracker. I can't emphasize enough how essential this one is in error reporting!

3. Steps to reproduce. Again, very universal. Explaining your steps might help the person helping you to identify where you've tried something the wrong way (ultimately it would most likely be the fault of the developer who hasn't made it intuitive enough then). And it helps the person trying to fix a bug to easily locate and test it.

Ok, and while this helps both the helper and the helped, I should admit one thing: developers, myself included, are sometimes just too lazy to create well formed error messages, making the whole thing more troublesome than it should be :lip: So here are three points for the other side as well.

1. Error messages should tell that a problem occured - obviously, not much to say about.

2. Error messages should mention likely reasons. Messages like "Could not save file" is just not helping the user in any way, but letting him know that permissions were lacking might.

3. Error messages should suggest alternatives. Not every user is knowledgeable enough to correctly interpret reasons. In the case above, a suggestion to save in a place where he has permissions could do.

You should see those addressed in another blog post about Spybot 2.0 :)

Spybot 2.0: updating concepts

PepiMK — Mon, 24 Nov 2008 21:33:47 GMT

Updating is an area where we feel quite torn, because it just cannot be solved perfectly. On the one hand, privacy paranoia should require all Internet connections to be established on explicit user request and choice. Background downloads are often among malware criteria, and as such, we wanted to avoid them for a long time.

On the other hand, there's user comfort. The average user does not want to be disturbed by having to actively care about his security software too much, and we can't blame him for that. Allowing an application to download at will requires (or at least should require) a lot of trust really. Of course, allowing a software to tell the user what it thinks is malware means a lot of trust as well already, so the trust may still be there. No reason to use it without a lof of thinking though.

The compromise we're going to approach is a dual approach. We'll still need manual updating for situations like running Spybot from a bootable CD, where background service downloads are not an option. So a kind of manual updater for such situations will persist. At the same time, we'll offer a no-interaction-required background download service.

The next issue with updates is about version checking. Currently, downloaded.ini is used to check which updates have already been downloaded. If you delete this file, it gets recreated based on file dates of archives in the updates folder. And if you install updates through a manual updater, it should get updated as well. Still, this method is far from perfect as soon as the user "plays" around in the Updates folder, e.g. to clean up old archives or create a portable edition - something he should be able to do without having to pay attention to the ini files in there. The 2.0 updating will therefore use dedicated updates per file instead of combining files in archives, and determine which are needed based on each files property (version resource for executables and libraries, other parts for data files).

Another side-effect of having one update per file is that it can easily support the new integrity checks, which would allow to replace single destroyed/corrupted files with originals.

On NT+ (2k, XP, Vista, ...) systems, a system service is the next point that we needed to discuss. On the one hand, a service would allow users with restricted rights to update Spybot. On the other hand, updaters are a field where many an antivirus application had security holes in the past. Since system services have system privileges, the interface for this needed to be tight, not comfortable (speaking from the developers standpoint, not a user one).

No screenshots here since this is mostly technical background stuff.

To sum up a few things:

No more shutdown of all updates while new updates are uploaded.
Fallbacks if main server is not available.
Background updating.
File-by-file updates to support integrity checks.
More safety measures to ensure authenticity of updates.

Spybot 2.0: user interface concepts: main windows

PepiMK — Mon, 17 Nov 2008 09:53:01 GMT

The next and probably last blog post about the user interface before getting to technical issues again is about the main windows, after we've already spend some time on information, confirmation and error dialogs.

Our starting point here was to look out for visual arrangements that would reflect systems standards, but are individual at the same time. Creating a GUI (graphical user interface) that follows standards is a basic requirement by anyone who believes in ergonomics. Using standard interfaces should help the user into an intuitive usage where things do what he expects them to do.

One issue about standards are custom controls. An application should only include those window controls (buttons, menus, lists, &c.) that the system offers. Items like flat buttons may look cool and individual for a short while, but they're really just an expression that individuality is restricted to tricks, costing the user comfort, and, similarly important, performance (noticeable on older machines at least). And while I have to admit our old user interface might not be the best example for that, we've at least tried to refrain from custom controls and skin engines where not necessary.

For Spybot 2.0, we tried to look for a more up to date visual concept than the old Outlook style was. The logical consequence was to look at Vista. You might or might not like Vista, but when you want to follow user interface guidelines, the official ones from the OS company are probably the best choice since they should be widely spread (even though I often have the feeling that they're globally ignored). This first led to the Vista-style dialog decisions posted earlier, and was used in designing main windows as well. Official Vista application windows often prefer a structure of horizontal tiles,

with a header with instruction and a few sentences at the top, quite like experienced in dialogs,
followed by a main data area (sometimes with a toolbar as an additional header), often a modern listview control,
an information panel and/or,
buttons at the bottom.
Additionally, windows might have a task list area at the left.

This is kind of similar to our old interface, where header instruction panel and a main data area including a toolbar already exist. We continued that structure, updated to a more Vista-like look (e.g. white background, original listview styles where the XP/Vista listviews could replace the treeviews in 1.x), but completely redesigned the surrounding.

The huge navigation list at the left is now gone, since it was too demanding by offering a huge list of options in advanced mode, which made the mode switching necessary (something we wanted to get rid of as well).

We first thought toolbars might find their way back to some windows, with the exact design still experimented with. And Office style ribbons are something we heard had quite a lot of positive feedback, but the funny blue office look just doesn't match a security application and looks to rogueish.

In the end, we thus decided for task bands like known from Windows Explorer that would show two boxes, one with direct actions, one with associated tasks the user might look for. The decision on the style of these task bands was a difficult one: they needed to be lighter and easy to distinguish from the old office bar to avoid any instance of false expectations of what could be found or not found there. A lof of the GUI was inspired by Vista, but in this case, the Vista style was to replace this with toolbar items in Explorer windows, and the existing task bands were to colourful to our taste and did not support as much structure. We therefore broke keeping in line there and decided for a lighter version of those task bands you know from XP.

To support keyboard users and users that have to depend on screen reader software, this task band has been mirrored into the main menu.

Which leaves one more thing, a central place to cover all the functionality, a place the user can use to select tools without coming from another tool, without having to select entries from the start menu, a kind of super menu to have only one desktop shortcut... you get the requirement I guess. Trying to look into modern concepts for such a thing, a few of us came up with something similar to the Vista welcome window. Which isn't such a new concept: windows to group program icons already existed in Windows 3.x, just were given up later. Of course the modern form has its advantages, among them the huge bar at the top we can use to display some important information like the date of the last update, various versions, on-access status, and more.

A collection of in-development screenshots (don't take them as final) can be found here.

Some interesting links on user interface concepts:

I promise next weeks blog post won't be about user interface stuff, but some technical details on another thing that needed improvement: the updater.

Spybot 2.0: user interaction concepts

PepiMK — Sat, 08 Nov 2008 18:05:20 GMT

Going beyond the last blogs topic on error dialogs, we wanted to go a bit further with these Vista style dialogs and use them in assisting the user in non-error situations as well. This gets a bit more critical for the advanced user, since he might get annoyed by this, so the option inside each dialog to not show this message again is extra important here (they can be re-activated at any point on a dedicated tab of the new Settings dialog).

One example of this approach is the Immunization start dialog on Vista:

Vistas UAC might be annoying to some users, but as an advocate of the concept (just maybe not in the realization of its support in many end user software), we want to support the user in using it properly.

The key here: applications should not always require elevation - that's a requrement described by Microsoft in their Certification rulebook, and imho important to keep the annoyance factor of UAC low. The modularization described in an earlier 2.0 blog post allows us to restart just the required part (the immunization) with just a click and a fast loading time here. And giving the user a choice allows non-admins to still use it in their allowed scope, as well as ask an admin to log in for them if wanted.

Another key here is offering the user details on what his choices are, and how they affect the operation, instead of just giving him a Yes/No choice that needs more careful reading to understand what the Yes and what the No means.

A second example might be the start dialog of RunAlyzer, which will now become, optimized in startup time, the new Tools section replacement of the Spybot-S&D package. This dialog was custom made, but has now been adjusted to show the same Vista style:

The elevation shown as the last topic will only show if applicable of course. Again, we offer to automatically get rid of the dialog when loading is finished (now quite fast, mich will happen later in the background when you need it). Choices are explained to the user. And still, he can at all times decide to ignore the dialog and proceed like he wants if he already knows the app.

That's it for today from the 2.0 front; your comments are again very welcome. Let us know if you feel this is helpful, or too intruding and you would want to do without such suggestions from the app.

Spybot 2.0: problem handling concepts

PepiMK — Mon, 03 Nov 2008 08:00:10 GMT

I'll start the talk about the user interface with error messages, where our conclusion from 1.x was that we did not stay true enough to a very important concept. Well, proper error dialogs are rarely encountered anywhere, but that should not be an excuse.

A good error message should have three purposes, possibly four:

Inform the user that something went wrong in terms he understands.
Make suggestions how to correct the problem.
Provide information that may help customer support trailing the source of the problem.
Offer those users who want to understand a background.

You'll often find one, and sometimes two of these in an error message, but very rarely all three in a language and structure that's adjusted to the users situation. And we've got to admit: the standard Windows error box does not really supporting displaying that information well-structured.

You can see our attempts at immunization errors, shredding errors and restore errors to see how we try to improve (and that we still have to finalize those texts, since they do not yet fulfill all our criteria).

Key points:

We try to offer the user an alternative (like elevation in the shredder dialog) instead of just displaying an error message.
A Hide/Show button is there to show the technically interested more information.
A clear headline indicating what the dialog is about, e.g. the direct question the buttons will decide upon.
Possible error reasons (immunization).
An option to skip his information in the future for those users who do not want to be annoyed by these messages.

Comments on how you would see this as a novice user (who might need the guidance?), or an advanced user (how big is the annoyance factor?), would be welcome of course!

The four columns of security for a safe online experience

PepiMK — Wed, 29 Oct 2008 10:09:01 GMT

Anti-Malware

Obviously, you'll find us positive about our own software for this purpose, Spybot - Search & Destroy, which should protected you well.
A very important advice when downloading any anti-malware application is to check the source of the file and the validity of the application twice. Do not use sponsored links on search engines for example - cheaters often try to sell inferior software "trials" labeled with the name of well known other products. Others are rogues that have only superficial functionality and might even install malware themselves to show they would detect something others are missing. A list of known fake or rogue applications can be found at Spyware Warrior.
Also, make sure the manufacturer of the solution you intend to install is a member of the ASC and does adhere to its standard (not all do, see below).

Anti-Virus

The classical area of protection that anyone knows about, initially centered on detecting files only, so we would still not recommend on depending on the malware protection from your AV (nor from that of your anti-malware - you'll need both).

Standard precautions to avoid the classical viruses haven't changed in a long time: do not open files you receive on disk or by email unless you scanned them with your antivirus application first. Do not open files a stranger sent you at all, nor files that seem to be coming from known persons, but are not accompanied with a personal letter (your friends machine might be infected and sending them out automatically). Verifying downloads by comparing their hash to one displayed on the website of the manufacturer is highly recommended (you can for example use our FileAlyzer for that purpose).

Our recommendation in this area would be Avira Anti-Vir.

Products we cannot recommend are:

Kaspersky Internet Security 2008 & 2009
McAfee InternetSecurity 2008 & 2009
Trendmicro Internet Security 2008 & 2009

Industry standards define software that impairs user control over material changes that affect their system security as potentially unwanted technologies, and these products force you to uninstall unconflicting competing software, thus lowering your computers level of security compared to other software. And should you really trust a company that's putting marketing way over your security?

A special bad place is earned by Symantec for their CEOs opinion about how much your privacy really should be worth.

Firewall

At the moment, we cannot really recommend any firewall product. On the one hand, we've (at some point over a long time, not continuously) experienced problems with all of them we tested and would not feel comfortable e.g. recommending a firewall that kills the system. On the other hand, we do not really believe in those one-thing-for-all solutions, where firewalls include anti-virus and anti-spyware applications that are often not as well maintained as dedicated solutions and may conflict with other installed security software.

After much thought, we've decided that we simply could not find any third party software firewall we can currently recommend with a safe conscience. The Windows Firewall could be regarded as sufficient for sensible Internet users; here's a pictured walkthrough by Microsoft. We'll update this part with better information when we come across it.

Spam Filters

If you've got an up to date version of your email application installed, it'll already come with a sufficient spam filter. If you enable it and it doesn't lead to good results immediately, you might have to "train" it for a few weeks by manually flagging spam emails. And the best protection against spam still is to deal sensitive with your personal data. Check twice or thrice where you leave your email address.

Spybot 2.0: modularity concepts

PepiMK — Mon, 27 Oct 2008 20:40:57 GMT

In the next weeks, I'll try to use the blog to announce a few things of Spybot - Search & Destroy 2.0, on topics where we would love feedback.

One important change in Spybot-S&D 2.0 will be that the functionality will be much more modularized. Not just one big .exe, but various smaller ones.

A few arguments:

Resources: you do not need everything Spybot offers all at the same time. By loading only those parts you need when you need them, Spybot can run faster, use less system memory, and on older 9x/ME systems, can use less of the precious GDI/user handles.

Speed: the app will simply show much faster.

Interaction: a challenge is to present it to the user in a way that is not affecting his ease of use; on the contrary, it should help him getting things done by presenting only that which he currently needs, at the same time allowing him to easily go to another part.

Updates & Maintenance: by having functionality separated, new functions or bug fixs mean that testing can concentrate on one module, and possibly those depending on it, but not on the full package, leading to faster and more stable updates.

Scripting/Scheduling: if you want to automate things, you can restrict that to the modules that offer the functionality you want to script, without the need to load the full, slow loading old app all the time.

The Modules:

Main Scanner (actually two new modules, a new scanner librabry and its user interface)
File Scanner (already known, improved by removal offer and some more features)
Cleaner (actually various parts to improve the cleaning capability, but visible to the user in only one instance)
Immunization (some may already know this from demonstration versions)
Settings (with a lot of legacy options removed)
Tools (the full capability as known from RunAlyzer, but sped up to have no waiting delay when opening it)
Quarantine (formerly known as Recovery)
Update (different from the 1.x one)
Shredder (similar to how its already moved out now)

Internally, there are even more modules, but this is what you might notice from a users side.

Do you have any comments on other good or bad sides of htis approach? Let us know!

Finally, a few screenshots not really saying that much since the user interface question will be part of another blog post and will still receive more attention before becoming final: Settings, Quarantine, Immunization.

What Symantecs CEO thinks about privacy really...

PepiMK — Tue, 21 Oct 2008 08:37:08 GMT

I just yesterday stumbled across an interview with Symantecs CEO John W. Thompson in German engineers magazin VDI-Nachrichten.

On the topic of a fake passport for "Elvis Presley" passing controls at an airport in the Netherlands, he suggested:

"Vorstellen kann ich mir da bereits eher - jetzt in Bezug auf das Internet -, dass man auf Basis des Leumundes eines Anwenders vorgeht. Man schaut, was ist das f�r ein Anwender, welche Seiten hat er besucht, welche Gefahr geht von ihm aus? Auf Basis dieser Infos l�sst sich dann ein Profil erstellen und Unternehmen k�nnen darauf entsprechend reagieren."

Translated into English, he said he could imagine, in regards to the Internet, that decision could be made based on the reputation of users. One could watch which websites he visits [and?] which dangers are resulting from that. Based on this information a profile could be created that would allow corporations [!] to react to that.

So, to get this straight, this man believes in monitoring Internet users to find out how dangerous they are, and give that information to companies.

Asked about the privacy issues there, he did not see any concerns there, and further critized European privacy dealings as going too far:

In Europa ist immer alles eine Frage des Datenschutzes. Die EU sagt: Eine IP-Adresse ist privat, das ist �bertrieben. Datenschutz wird �ber alles gest�lpt, dient oft nur als Vorwand. Ich frage Sie: Was ist sch�tzenswert an einer IP-Adresse?

Next to the issue that monitoring visited websites goes a bit beyond simply IP addresses, static IP addresses are not that different from a phone number or postal address. I remember very well from university times that a dorm IP could easily be tracked to the name of a person in minutes. Static IPs can be attacked to get more information about the owner - and Symantec very well knows how that many computers are not safe enough to withstand that. IP addresses might thus easily and without official requests involved uncover the personal identity of a websurfer.

Anyway... creating profiles on all visited websites and sharing them with companies as a way to make the web safer? Seems like someone didn't read George Orwells 1984 (or took his inspirations from that). All else I can say is that I would not trust the anti-spyware software from a company whose CEO believes in total monitoring of users (or just call it spyware) itself!

Elevation of Privileges with Adobes Reader 8.x plugin

PepiMK — Wed, 02 Jul 2008 06:50:03 GMT

Since Adobe Reader 9.0 just got out, let me give you an explanation why it is useful to update.

Adobe Reader 8 has a feature to save memory, which is a good purpose in itself, if it wouldn't go a bit too far. When you open your first PDF, a full instance of Adobe Reader is opened, but whenever you - or anyone else in your WindowStation - open additional files, parts of the already open instance are used.

This in itself is no problem on single-user machines, but as soon as more than one person is using the computer, or more specifically if one person is using the computer using multiple accounts, a PDF opened with restricted rights can gain the rights of the first Reader instance, e.g. administration rights.

Let's for example assume the situation we tried to address through our AlterEgo application, since it allows easy reproducing of the problem: most users are using administrator privileges for their daily work, and with the Internet being source number #1 for any kind of malware, the sensible move is to use browsers under the privileges of a separate, restricted, user account. The Linux world has been using this concept for decades in an even stricter sense: using a restricted account for daily work and sudo-ing tasks that require administrator privileges (for this safer scenario, the exploit will work as well, the attached example would just have to be adjusted by switching roles). In the Windows world, sudo is implemented through runas.exe.

Now, you would assume that if your browser is running restricted, any PDF you view on the net, like those worms reappearing every few months targeting new exploits (for example this latst one), would run restricted as well. But if you did open a PDF as an administrator before, the PDF opened in the Reader plugin fully integrated into your browser will open with privileges of the administrator account as well. To test, try to save it through your browsers Save function and you'll only be able to see the restricted users documents folder, but from the plugins Save button, you'll be able to see and save in the administrators home folder.

Attached to this post is a batch file to automate demonstration of this.

The danger of it? Depends on how many Windows administrators (And those who do not even know they are) do actually try to protect themselves, since if their browser would run on an administrator account as well, there's nearly no further elevation possible either way. The ugly thing is that Adobes single-user operating system approach to this reduces security exactly for those users who try to work safer in the first place.

Sorry it took me so long to post this proof of concept; as you might've seen I wanted to some weeks before, but communicating with Adobe was one big nuisance. If you're a paying owner of any Adobe product, you probably have already encountered their support department, which I rank #1 in arrogance among any commercial company I've been in contact with so far. People there seem to get paid by closed case, so that solving a problem is an absolute negligibility. Cases are closed after copy'n'pasting irrelevant text. Errors on the website are not forwarded to be fixed, e.g. if an email form is too exhaustive and rejects valid email addresses, the recommendation would be to create a new email address to contact Adobe. Only after nearly a dozen emails of begging to listen, they acknowledged and fixed the bug. Not that they would've informed me about a bug fix of course, but todays test on Reader 9 showed that it is not reproducible any more.

My conclusion: should you ever hear anyone from Adobe complain about pirated Photoshop copies on the net, give them a healthy laugh - my full understanding goes to everyone who doesn't want to be humiliated by these guys when requesting the paid-for support. Wait, did you expect a conclusion about the bug? Well, the bigger the bug, the more people between you and the ones who understand a bit about security issues, there's nothing new on that front really.

Attached Files

AdobeReader-EoR-PoC.zip (1.2 KB, 743 views)

Internet Explorer 7 and the never-fixed buffer overflow

PepiMK — Fri, 06 Jun 2008 07:16:35 GMT

Sorry for going at Microsoft again in my second blog post here, but since the text was already written mostly, it's something I can easily add ;)

Buffer overflows are a very typical source of security problems, emerging from a bit of carelessness on side of software developers. Buffers are areas of memory, used for example to contain text, and C [a computer language] developers need to take extra care to always manage their maximum length when handling them, since by nature, they're only limited by the first "zero" character.

See the problem? You have the text Hello World, which has 11 letters. Add one zero character (not the "0" you know, but an internal value 0), and the computer will know the text ends at the d. Forget to reserve that 12th letter or copy something longer than 11 letters, ignore the length, and you've got a problem, since the computer will continue to read text somewhere in memory that's beyond the area you've reserved for use for this text.

I might blog about that topic from a developers point later, for now, I wanted to make public such a buffer overflow in Microsofts Internet Explorer 7, which I first reported to Microsoft on November 4th, 2006 (receipt was confirmed), and which still has not been fixed. Yes, that's 19 months now, and I stopped thinking it would get fixed without public awareness of the bug. So here's a report of the buffer overflow, as sent to Microsoft (a bit reformatted for the blogs vBCode of course).

Summary:

When manipulating a registry value, a buffer overflow can be provoked.

Symptoms:

Random tabs, random text on options dialog, crash on exit.

Details:

By removing the terminating zero bytes, the size of the buffer previously allocated seems to overflow into otherwise used memory.

The reason for this problem seems to be based on the fact that while any application can read the size of a registry key, IE seems to make use of this only to determine the size of the buffer to allocate, but depends on a correct termination to actually stay inside this buffer. Missing consideration of string lengths is a very typical reason for buffer overflow problems.

Steps to reproduce:

Run Internet Explorer (or use ie7-reg_multi_sz-bug.reg and jump to #10).
Open menu Tools -> Internet Options.
Enter a bunch of startpages, in this example
http://www.google.com/
http://www.altavista.com/
http://www.yahoo.com/
Press OK and close IE.
Run regedit.exe.
Navigate to HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\.
Right-click Secondary Start Pages and select Modify Binary Data.
Delete the two last \0 bytes (see ie7-reg_multi_sz-bug.png).
Press OK and leave regedit.exe.
Run Internet Explorer again.
Take a look at the startpage list in the Internet Options.
Close IE.

At this point, you may notice either one or more of these:

More tabs opening on step 10, with random names like http://tp/ or http://0.0.0.4/ or whatever seems to be in memory (often only on second or third start of IE in a row).
On the Internet Options panel in step 11, see anything from random text yahoo.com to real other domains.
On exit (step 12), Internet Explorer is now throwing an "unknown software exception 0xc0000005 at address 0x03cc4026)" and/or a "Runtime error 216 at 0x03cc4026" (reproduced this on 7.0.5730.11 only).

Affected versions:

7.0.5730.13 (XP Pro x64 download version, both 32 and 64 bit)
7.0.5730.11 (XP Pro x64 download version, both 32 and 64 bit)
7.0.5744.16384 (from Vista x64 RC2 download, both 32 and 64 bit)
Other versions were not tested, but likely the same; the problem was retested and verified about monthly, last time April 4th, 2008.

Danger:

I have not tried to exploit this, and I don't see any malware doing this as well, since it would probably need further registry manipulations and lead to no further privileges than those that must alread exist to use it. The issues only implication would be crashes.

So, while the possible danger of this bug alone has a tendency to be non-existent, the background would be that Microsoft does not see a necessity to fix a type of software bug that is a very common source of situations where software gets exploitable.
From a developers standpoint, there should never be a policy of ignoring a buffer overflow because it is unlikely to cause harm, as done by Microsoft here.

Attached Files

	ie7-reg_multi_sz-bug.zip (431 Bytes, 669 views)
	ie7-reg_multi_sz-bug-screenshots.zip (96.2 KB, 699 views)

Microsofts Web 2.0 live attempts a bad example

PepiMK — Mon, 02 Jun 2008 20:08:38 GMT

It's been on various tech news recently that the great SysInternals tools by Mark Russinovich have now been made available as live versions on http://live.sysinternals.com/ .

They're a great set of tools, very useful when hunting for problems, and I have to admit the Web 2.0 idea is quite tempting here. Web 2.0, or it seems to be called Live in Microsofts terms, surely is a tempting thing in general - having your applications wherever you go, right there on the Internet that's available everywhere.

But with standard Web 2.0 applications, you do run them in the relatively safe, more or less sandboxed, browser environment. Sure, you're probably one belonging to the majority of users running the browser from an adminstrator account, but still, malware on typo sites first needs to exploit a security hole, and furthermore, standard web applications need a logon on a page you visually check.

The SysInternals tools though are tools designed to be run under administrator accounts, and Microsoft advertises them now to be run without even having a visual check of the page around them. The only check you have is the Authenticode certificate, when Windows asks you whether you want to run software from Microsoft Corporation.

I'm not implying here that Microsofts SysInternals Live server could be hacked, but this live system is designed to be used on some machine where you don't have the tools yet, and want to be quick without checking a site, so you're actually going to type, from memory, \\live.sysinternals.com\Files\procexp.exe to run the application.

How long will it take until malware appears on the first typo domains like szsinternals.com or sysinternal.com? And contrary to a regular download, you won't be able to notice until the code has already executed (exception being to be very careful about the certificate).

And another topic of course is that Microsoft is acting as an example for others, showing users that it is OK and hip to run executables directly from the net.

So, that's my first blog entry in the new blog here at the forums, created for news that might not exactly be worth Safer Networkings main news list because it gets a bit techy. Sorry for it's length, and let's hope I'll continue it ;)