The superuser is probably taking you (and
/bin/su) out of
/etc/sudoers (and probably
/etc/passwd) as I type this.
If you don't know the superuser password, in order to switch to the superuser account using
/bin/su, then you obviously aren't the actual superuser and that is someone else. The person to fix this is the actual superuser, because you've opened a massive security hole and created a right mess. The actual superuser, upon seeing this mess, has probably gone into BOFH mode and is busy removing your ability to ever again run things under the aegis of the superuser account, given what happens when you do.
Basically, you've opened a window where anyone with an account on the machine can compromise it and gain superuser privileges almost trivially easily. (Some executables regularly run under the aegis of the superuser account, in response to
cron jobs and the like, are now world-writable.) Tidying this up safely is a whole lot of work, because one has to work on the basis that any executable anywhere on the system is potentially compromised by now. Anyone who could remotely log in to an account on the machine via SSH, or exploit any other means of gaining shell access as an ordinary user, could have compromised it.
Your two-liner from an unnamed post on a discussion forum is entirely missing the security ramifications of what you've done. But that is in part because it addresses a different situation. The posts you are no doubt looking at are where people have changed the ownership of
/usr/bin/sudo, and have not made it world-writable like you have.
Your superuser, if xe knows xyr stuff, will not miss the security ramifications. But xe won't be happy with how much work you've just created for xem.
For the poor superuser's benefit: