How much of BIP 62 ("Dealing with malleability") has been implemented? BIP 62 lists nine source of malleability:


Non-DER encoded ECDSA signatures
Non-push operations in scriptSig
Push operations in scriptSig of non-standard size type
Zero-padded number pushes
Inherent ECDSA signature malleability
Superfluous scriptSig operations
Inputs ignored by scripts
Sighash flags based masking
New signatures by the sender


...and proposes new rules that would fix the first seven. How many of these fixes have been implemented in Bitcoin Core?
Most of the fixes have been implemented in Bitcoin Core's master branch, or earlier versions, as standard transaction checks that prevent default Bitcoin Core nodes from relaying or mining transactions that break the rules.  Here are some details: 


  
  Non-DER encoded ECDSA signatures
  


These are currently non-standard, so Bitcoin Core nodes (since 0.8.0, IIRC) by default won't relay or mine them.  When the BIP66 soft fork is successful and version-3 blocks become mandatory, this rule will be enforced on all confirmed transactions.


  
  Non-push operations in scriptSig
  


These are also currently non-standard, and are completely forbidden for signature scripts spending a P2SH output.  I don't know when they were first made non-standard, but I suspect it was 0.8 or before.


  
  Push operations in scriptSig of non-standard size type
  


These were made non-standard in 0.9.0, where they're called "non-canonically-encoded serialization sizes".


  
  Zero-padded number pushes
  


This will be non-standard in 0.10.0.


  
  Inherent ECDSA signature malleability
  


This is currently allowed, and several popular Bitcoin programs still do create full-range signatures.  Getting those programs to update to using only low-S values before BIP62 is implemented would be nice, but it isn't critical because the new BIP62 validation rules will only apply to version 2 transactions.  Programs that don't update will still be allowed to create version 1 transactions even after the soft fork.

The advantage for programs using v2 transactions is that they can generally be constructed to be non-malleable by third parties, so v2 transactions can more safely be used for applications like the initial bond part of establishing a micropayment channel.

Edit: an earlier version of this section incorrectly said getting programs to create only low-S signatures was critical.  Thanks to @PieterWuille's comment below for pointing out my error.


  
  Superfluous scriptSig operations
  


Non-standard since 0.6.0.  In master, this test has moved here.


  
  Inputs ignored by scripts
  


This is partly addressed in 0.10.0, but see the note below.


  
  Sighash flags based masking
  New signatures by the sender
  


Per BIP62, "The first six and part of the seventh can be fixed by extra consensus rules, but the last two can't. Not being able to fix #7 means that even with these new consensus rules, it will always be possible to create outputs whose spending transactions will all be malleable."

In short, rule 7 doesn't have a complete solution and rules 8 and 9 don't have any solution.  (Indeed, the malleability from 8 is a feature, and fixing 9 would require a different signature scheme.)