For the most part, you're correct. Applications with a safe type system (not just .NET or Java) don't allow the application to violate those constraints.
Buffer overflows and many other remote-code exploits occur because the constraints in those languages and runtimes provide no checking and cannot guarantee the program won't do something like execute arbitrary code in memory. Safe systems verify the code to be free from those effects.
(As a side note, C# can still perform unsafe actions and set itself up to execute arbitrary code. It's just rather cumbersome and unlikely to be used in a real application.)
The security holes you would see in a managed browser would be if it let arbitrary code be loaded, using the CLR as a safe environment. While the CLR generated code (i.e., the JIT'd of your application) will be safe, the loader and verifier themselves are usually written in a lower language. There's been a few (I think 2 for .NET?) security holes where a maliciously formed assembly could force the actual CLR to execute arbitrary code. However, these are relatively rare issues, and the surface area is far less than it'd be otherwise.
So, yes, a fully safe, managed browser itself wouldn't fall prey to those specific exploits. But that also means you'd have to have your plugins written and executed in a similar way (Flash?). Finally, there are other security holes that can be targeted, but usually they will be less severe than you'd find with an unmanaged application. Cross-site scripting, for instance, would still remain an issue. But at least you wouldn't have "viewing a document can execute arbitary code" type problems.