If you have a phone number multiple times in your address book (this means the phone memory + the SIM), the phone number is displayed instead of the associated name (this seem to include incoming phone calls, call logs, SMS messages, etc). There are a lot of complains, here are a few links from the Nokia message boards:

• N96: When recieving call its displays number rather then contact name?
• N82 caller display: displays number but not the name
• E71 sms sender’s name not showing..!

To solve the problem, you “simply” have to delete one of the entries. Of course locating the entries might be tricky (if you can synchronize your phone with a computer, it might be easier). And even though people try to defend this behavior (“If the phone finds the same number against more than one name, it doesn’t know which to use so, perfectly sensibly, it defaults to showing the number”), but in fact it smells like a “decision by committee”:

• Displaying any of the names gives more information than displaying the phone numbers
• Displaying one of the names would make it infinitely easier to locate the source of duplicates
• From a programming point of view, it would be easier to stop at the first match (then again, I’ve heard some theories that the software does some internal hashing and does the lookup based on that, which may mean that “stopping at the first match” may not be so simple)

My final thought? Yes, it is stupid, but it only affects a small portion of the users, and if you know the problem, you can work around it.

Picture taken from Mike Licht, NotionsCapital.com’s photostream with permission.

import java.lang.reflect.*;

public class ReflectMe {
 public static int foo = 1;             //*1
 
 public void test() throws Exception {
  foo = 2;                              //*2
  Class c = Class.forName("ReflectMe");
  Field f = c.getField("foo");
  f.setInt(this, 10);                   //*3
  System.out.println(foo);              //*4
 }

 public static void main(String[] args) throws Exception {
  ReflectMe r = new ReflectMe();
  r.test();
 }

}

One would expect that a watchpoint set on foo would be triggered on the four different marked lines. However I found that it isn’t triggered on line #3. At this point it is unclear to me if this is a limitation of the JVM or Eclipse and I didn’t find any relevant information, so I submitted a bugreport and hope that people smarter than me can figure this one out :-).

Update: just as I suspected, the problem is that the JVM has this behavior. Thank you for the great guys and gals working on Eclipse for such a speedy response.

PS. The code where I ran into this behavior was a configuration loader which used reflection to set the values read from the configuration file (ie. you specified something com.foo.Bar.exampleVariable = 10 and it used reflection to traverse the class hierarchy and assign the value). While very cool and has the advantage of settings “just working” with zero code for new fields, it also has some disadvantages (for example: are you sure that you want to expose your variable structures? using this method they effectively become part of your public interface) to which now I can add the problem that assignment is not observable via watchpoints (which is not a big problem if you do know what is going on – but it you don’t, it can seem quite magical – and dismaying).

Under no circumstances (ok, I rephrase: only under extreme circumstances) should you use DBD::PgPP. It is old, not very performant (given that its implemented in Pure Perl) and has some nontrivial bugs. An example for one such bug is the following:

my $sth = $dbh->prepare('SELECT foo FROM bar WHERE baz = ? AND fuzz = ?');
$sth->execute('a?b', 'c');

With PgPP the actual query it will try to execute will be something like: SELECT foo FROM bar WHERE baz = a'c'b AND fuzz = ?. I assume that what it does is that it takes the parameters provided to execute one by one and looks for the first question mark in the query. But given that the first parameter itself contains a question mark, the method fails…

So how do you install DBD::Pg if there aren’t in the ActiveState PPM repositories?

1. Go to the dbdpgppm project on pgfoundry
2. Download the correct PPD file for your needs (depending on the Perl version – 5.6, 5.8 or 5.10 – and if you need SSL support or not)
3. Issue the following command:
   

   ppm install the_downloaded.ppd

<html>
    <frameset rows="20,*" border="0" frameborder="no">
        <frame name="menu" src="menu_frame.html" scrolling="no" noresize="1">
        <frame name="work_frame" src="">
    </frameset>
</html>

First of all you would say: but frames are so 1998! And you would be right. Frames are outmoded, deprecated and a usability nightmare (because you can’t bookmark the exact state of the frameset), you have to use them in certain situations. Like, for example when providing a "unified menu" in an intranet where you can’t (or don’t want to) touch all the sub-sites referenced. "The right tool for the right job".

Back to our problem: the page from the upper frame contained a bunch of links targeted at the lower frame in the form of:

<a href="http://www.example.com" target="work_frame">Example</a>

The problem was that while on all "sane" browsers the link opened in the lower frame, Internet Explorer (both version 6 and 7) insisted on opening a new window for the link. Finally I got the idea to create a blank page and set the lower pane to it:

<html>
    <frameset rows="20,*" border="0" frameborder="no">
        <frame name="menu" src="menu_frame.html" scrolling="no" noresize="1">
        <frame name="work_frame" src="blank.html">
    </frameset>
</html>

Magically everything worked. So there you go: IE + Frames = Headache (from banging your head against the desk), or at least Magic.

PS. I never tried using "about:blank" instead of an explicit blank page, which seems to be standard (I don’t know if official or unofficial) between the major browsers. Possibly it would also work (and has the advantage that you don’t have to explicitly code an "empty" html file).

• Update to PHP 5.2.1 and watch out for the next version and update to it as soon as it comes out. Do not PHP4, because there is a vulnerability which will not be fixed by the developers (because PHP4 is considered old code).
• Install Suhosin (unfortunately it is currently only available for Linux)
• If you have the Zend platform installed, take on look here to see if you are vulnerable to these exploits
• Disable the following functions (there are some very common functions here, so unless you run your own server, you won’t be able to generally disable them):
  • phpinfo()
  • substr_compare() – if you really need this function, you can find a replacement for it written in PHP on the documentation page (I didn’t test it, but it looks like it should work).
  • mb_parse_str()
  • iptcembed() – already disabled if you disabled the GD extension
• Disable the following extensions (they are rarely used, so in case you are a shared hosting, most probably you can get away with disabling them – of course if you host your own servers you should disable all the extensions which you don’t use!):
  • WDDX
  • Ovrimos (in PECL, but you may have installed it with an older version of PHP)
  • The zip extension from PECL
  • bz2_filter
  • SQLite – the issues with it are fixed in PHP 5.2.1, however be sure to read the description here before relaxing (because you might use a different version than you think).
  • the GD extension – this is relatively widely used, so you can get away with disabling it only if you own you own server

Also my previous recomendations remain valid:

• Run PHP as CGI rather than shared module
• Configure your firewall rules strictly (if you don’t have anything on port 4444, do not open port 4444!)
• Consider using mod_security. While it is not perfect, it provides you with an added layer of security
• If you are using a shared host account, consider moving to dedicated servers of VPS’s! If you decided against it, consider it again! Think about this

Of course even you apply all these measures you won’t be 100% safe, because some bugs remain unfixed and Esser hinted that he might be back later this month with an other month worth of PHP bugs.

Now for the security related stuff:

The Month of PHP Bugs continues with two new vulnerabilities. Fortunately these bugs were disclosed to the PHP team beforehand, so updating to the latest version solves them. Also, one of them is in the WDDX extension, which seems to be in a particularly poor shape, and you might consider disabling it (because in my 7+ years of PHP programming I’ve never seen code using it and had to look up myself what it stands for). Of course we all know that all non-used extensions should be disabled, but my advice was given from the point of a shared hosting provider whos goals include providing her clients with as much functionality as possible. Then again these (and most probably the coming) vulnerabilities show that once you run someone elses code (be it in whatever high language you may think is sufficiently sandboxed), you take on risks (and big risks with PHP).

Joanna Rutkowska held her presentation at BlackHat (slides available) about bypassing hardware-based memory readers. The gist of it is that (a) you can map certain memory ranges to go to I/O ports rather than the memory (the so called Memory Mapped I/O) and (b) the DMA controller goes through an extra chip while reading compared to the CPU. The attack is to reprogram that extra chip, resulting in showing different results to the data acquisition card than to the CPU (effectively hiding any code the author wishes). My opinion: this is certainly interesting, but can easily fixed by the vendors of the memory imaging cards. Then again, to perform such manipulations, the code must be in ring-0 (or kernel mode) and then it becomes an arms race (for example you can use the CPU debug registers – with some restrictions – to watch the I/O as show by this recently published article on rootkit.com). Again, rootkits and anti-rootkits are irrelevant, and people (programmers, system administrators, policy makers) should try to implement the policy of least privilege where possible.

And finally, there is a post over at Arbor Networks which talks about how every type of file (including RTF, PDF, DOC, etc) can be dangerous. It seems that the days of reject executable attachments are gone. What can we tell our users? In my opinion we should stick to the old message (do not open executable attachments) for two reasons: to be consistent and because this filters out a large portion of the nasties out there. As for these other issues: patch, patch, patch.

My advice remains the same: forget shared hosting (both as a client and as a Service Provider) and patch, patch, patch – also consider things like Suhosin and mod_security. I know that (especially the later) can be a pain in the rear end to configure, but the alternative – being owned or DoS-ed out of existence – is by no means better.

PS. This week seems to be a bad one for PHP security since the distribution server for WordPress (a popular blogging platform written in PHP) was compromised – my respect to them for saying cracker, not hacker – and contains a backdoor. Via Slashdot.

The situation currently is: if you are running on a dedicated (virtual) server, you don’t have anything new to worry about (since supposedly your programmers don’t intentionally try to crash your webserver). On the other hand if you are running (or using) shared hosting, be worried, very worried. One malicious user or one easily hackable PHP script can make your server an easy target for DoS attacks with these bugs.

It seems rather curious that the PHP developers were against the fixing of these flaws (if you can believe Stefan Esser, after all you have to take the word if all involved parties with a grain of salt), because it is something that Perl is doing, most probably for many years.

If all the bugs stay in this area, people running / using dedicated hosting will be relatively safe (as safe as were until now). The clients of shared hosting companies should try to migrate anything remotely important or confidential over to dedicated hosting if the given shared hosting company provides PHP (and most of them do, except for the ASP ones) or at least convince them to install Suhosin (which they probably won’t). Don’t even try to convince them to use mod_security, because while Suhosin shouldn’t require many configuration and most probably won’t break anything for anybody, this certainly will.

I completely disagree with the decision for security companies, researchers and individuals to make information on vulnerabilties, or how to exploit them, public without following responsible disclosure – this is not very responsible Organizations should NOT do business with entities that put our networks at risk – period!

Needless to say I disagree with him completely, one of the reasons being that is business suit type of person (a former Gartner analyst). That said, over on the securosis.com blog you can read a very detailed and very balanced description of the disclosure process and the problems with it.

If you still prefer to read this blog posts, here are the key points you should keep in mind when discussing vulnerabilities:

• The bugs are not created by the researchers. The bugs are created by the company (or rather the programmers of the company) so morally speaking they are responsible for it (unfortunately with most modern EULAs they have no legal responsibility)
• The fact that a bug is not widely known doesn’t mean that it’s not known at all. It is very possible that a limited set of people have knowledge of it and are using it for nefarious purposes.
• Given this fact, any disclosure whether its coordinated with the vendor or not, is a good thing / public service. Even more so when you consider that these very, very smart people do the work for free which the given company failed to do, even with the (hopefully) massive amount of money put in the QA department.
• One blog post pondered the fact that many people are in the fame business when publishing vulnerabilities, however you have keep in mind that: (a) as one commenter noted: even if they only supply a reliable way to reproduce the bug, this is enough for the programmers to fix it and (b) either there is a sudden increase in smart people (or at least who know how an XSS vulnerability works) or the quality of the programs if very, very low. Either way, remember: they are doing the QA departments job for free! (This is not to say that you should fire your QA department, but at least thing about bringing some of these people on your team)
• Finally, I have to wonder: would the verdict of the poster have been so harsh if the subject of the talk were business people (as opposed to technological people)?

In conclusion: this is a technological problem first and a PR problem second and should be treated by the companies that way. (Or better said: it is an economic problem first, so treat it like such: offer rewards for vulnerabilities and fix them as fast as possible – think of it as the cost you pay for not following strict security guidelines and rigorous QA testing)

To be specific: in one of my Perl scripts I wanted to send mail. The problem was that I didn’t have access to a SMTP server on that machine. After toying around with the example code of Net::SMTP::Server I concluded that it didn’t work and went off to find some lightweight solution. One of the more promising solutions was RunMail, however I was still uncomfortable about running binary code of unknown origin on the server. As a results I fired up telnet and the Perl debugger and stepped into the library source code. There I found the following part:

    # Loop through the recipient list.
    foreach $target (@{$self->{TO}}) {
 my $rr;
 my $domain = /@(.*)/;
 my $res = new Net::DNS::Resolver;
 my @mx = mx($res, defined($1) ? $1 : hostdomain);

I promptly replaced the line so that $1 would be set, and voila, it works!

    # Loop through the recipient list.
    foreach $target (@{$self->{TO}}) {
 my $rr;
 $target =~ /@(.*)/;
 my $res = new Net::DNS::Resolver;
 my @mx = mx($res, defined($1) ? $1 : hostdomain);

Now, if this would have been a binary library, I would had to: (a) get the source code (b) set up a build environment (c) compile from source (to get the debugging symbols) and (c) figure out how to integrate the debugging version with the release version such that I get a breakpoint where I need to and I get the debugging symbols. And I didn’t even speak about the rich introspection capabilities of scripting language debuggers!

Update: the actual problem was in Net::SMTP::Server::Relay, not in Net::SMTP::Server.

Update: below you can see the full code of the module (since it is rather short). The part shown with bold is the one which needed to be changed:

package Net::SMTP::Server::Relay;

require 5.001;

use strict;
use vars qw($VERSION @ISA @EXPORT);

require Exporter;
require AutoLoader;
use Carp;
use Net::DNS;
use Net::Domain qw(hostdomain);
use Net::SMTP;

@ISA = qw(Exporter AutoLoader);
@EXPORT = qw();

$VERSION = '1.1';

sub _relay {
    my $self = shift;
    my $target;
    
    # Loop through the recipient list.
    foreach $target (@{$self->{TO}}) {
 my $rr;
 $target =~ /@(.*)/;
 my $res = new Net::DNS::Resolver;
 my @mx = mx($res, defined($1) ? $1 : hostdomain);
 
 next unless defined(@mx);
 
 # Loop through the MXs.
 foreach $rr (@mx) {
     my $client = new Net::SMTP($rr->exchange) || next;
     
     $client->mail($self->{FROM});
     $client->to($target);
     $client->data($self->{MSG});
     $client->quit;
     
     last;
 }
    }
}