The chain is not verified "by itself". A given system (say, a Web browser) will consider a server's certificate as valid because it could build a valid chain (with all signatures corrects and matching names and all the rules of X.509) which ends with the certificate to validate (the server's certificate), and starting with a root CA that the client already has.
Signatures don't create trust, they transport trust. It still has to start somewhere. Each client (either in the browser or in the OS itself) comes with a list of "trusted CA": these are the public keys and names of some entities which are deemed "trustworthy" (you did not choose them yourself; Microsoft did that for you; but, anyway, as long as you use Microsoft's software you are trusting Microsoft for not playing nasty games on you). The root CA are "trustworthy" if you trust them for not issuing certificates with fake information: when a CA issues (sign) a certificate for some entity E, it is supposed to make sure that the public key that the CA puts in that certificate, along with E's name, is really owned by E. Similarly, when a root CA delegates its power to another CA (then called intermediate CA or sub CA), it makes sure (through audits and binding contracts) that the sub CA is indeed trustworthy, in that it will apply the same rules.
That's the concept of a Public Key Infrastructure: as a client, you know a priori a handful of public keys owned by trusted CA, and you implicitly trust everything that these CA signs. The certificates assume a tree-like structure, with the root CA as, well, the tree root (hence the name), and the end-entity (SSL servers) certificates as leaves. A certificate chain is really a path from the root to a given leaf.
If a root or intermediate CA becomes untrustworthy, for instance because it was hacked and issued a fake certificate (a wrong association between name and public key), then the recovery entails severing the bad branch, a process known as revocation. In practice this does not occur often for big commercial CA (the ones that are trusted by default in Windows or Firefox); say about once a year. E.g. that one occurred a few days ago, and both revocation and a fail-safe patch from Microsoft block any attempted usage of the rogue certificate. In practice, normal attackers (say, for phishing purposes) don't bother obtaining "valid" certificates for their fake servers.