Take a look at the flags set in the file and you’ll notice the suid-flag is set. The file flags look like this:
-rwsr-xr-x (note the ‘s’ in there)
Take a look at the passwd file, you’ll see the same flags set.
This means that this program can be executed as a normal user but may elevate its own permissions via code. With passwd for example this is necessary because you need to be able to change your own password, which requires the program to have the permission necessary to read and write the shadow password file, which is root only, but you have to be able to run it with your user privs only, even if you have no sudo rights on the machine you should be able to change your (and only your) password.
You run the exploit as the normal user. Without calling setuid, you would run the program with the permissions of your user. But by calling setuid in a file like this (with the suid-flag set) means that you change the permission settings to the user you specify (in this case 0, i.e. root).
This exploit works ONLY because the setuid-flag ist set. And it goes without saying that files that have the flag set should be very well audited and checked for flaws because … well, you have seen first hand what happens if you don’t.
Another flag you want to look out for is the setguid-flag. Same reason. There, you’d have an s in the group triple of the permission flags instead of the owner triple.
P.S. Just watched the video, he pretty much explains it at 33:00. Could’ve saved me all that typing just by watching…