Short answer: No, MIT licenses do not obligate you to release your code as MIT.
Long answer:
Let's take a look at the MIT license
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
And let's look at the heart of it:
to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software
In layman's terms, software that is licensed with the MIT license is saying "use this any way you wish." And the only exception is that you need to abide by and include their disclaimer of warranty if you keep their portion of code under the MIT license.
So let's say you want to take an MIT library and re-release it as only a GPL library. You can most certainly do that, and the FSF has provided notes: 1 and 2 on that exact subject.
Note that you didn't make any change at all whatsoever to the project except to claim ownership of your fork of the project that you then released as GPL. But also note that you cannot restrict others from continuing to distribute the original project as MIT. You can also restrict them from distributing your project as something other than GPL.
But what about that disclaimer of warranty and copyright notice?
You cannot take away someone's copyright to a creation they own. And even though you legally claimed ownership of the code (as explicitly permitted by the MIT license), you should include a notice to the effect of "portions of this code were originally created by such and such" and state the date of their claim to copyright. But you don't necessarily have to do so since you've re-licensed their project and assumed liability.
And what about the warranty statement? Since you re-licensed their project, you assumed liability for the distribution of that code. If you re-license, you better choose the new license terms carefully or be prepared to service warranty claims that may get raised.
So this example isn't the free lunch you thought it might be. By re-licensing, you're taking on liability and responsibility for the project that you may not want. It's something you have to think through and decide upon.
Another thing you need to consider in this example is that you can't use the reputation of the MIT licensed code as a supporting mechanism for your re-licensed version of the code unless you abide by the conditions of the MIT license - which are to include their copyright and include their disclaimer of warranty. If you incorporate it and re-license it, then it's your's and not their's. So you can't use their reputation for your benefit. At least not without noting the sub-module licensed under the MIT license.
Bringing all of that back around: using MIT licensed code in your project doesn't force you to use the MIT license for your project. And you can even completely incorporate the MIT licensed code within your project without any viral effect.