In Scrum there is no specific advice on how to handle defects, other than knowing that they need to be fixed. The general approach is that everything which needs to be done for the product, has to be listed into the Product Backlog. While that remains true, with this short article I'll try to give a better overview on what to handle and when, in the hope of giving you a more structured approach.
First things first: don't call them "Bugs"
It seems to be a silly distinction, but - in hardware development - the word "Bug" was used to signal the fact that an actual bug, probably attracted by the heat of some component, was ending up on a circuit board, and accidentally frying itself, by putting its legs in the wrong places, and causing a short-circuit. This was a real problem, and not a metaphor (more details in this article http://theinstitute.ieee.org/technology-focus/technology-history/did-you-know-edison-coined-the-term-bug).
The most interesting thing about this, is that bugs disrupted the development of a board, as external agents, not as generated *defects* out of a poorly controlled development process. So calling them bugs, in software development, feels like an excuse to externalise responsibility to someone else, rather than simply admitting that we made a mistake. We have now not only to fix it, but to improve the process, in order to avoid creating even more defects.
What is a defect then?
A defect is a misbehaviour of the software we produced. It is a non-compliance with defined acceptance criteria expressed by the user/client/stakeholder or generally collected by the Product Owner. A defect is not something we discover as missing, and it is not something which would make what we developed better. Those are more like changes.
This distinction is aimed at avoiding discussions that would lead to finger pointing - I know you have been through this already - and aimed at understanding how to handle the two different concerns.
How to handle defects, changes and not Done
First, imagine that you are in the middle of the Sprint, and while working on one of the Product Backlog Items (probably a story) you find out that you can't get that to Done, because one of the acceptance criteria is not fulfilled. This is an impediment, that doesn't allow you to get the story to Done, perhaps because of a defect you have introduced during the development. Agile teams tend to fix these sort of defects right away, otherwise they would carry on undone work (equivalent to lean inventory).
Second, suppose that you have completed all the stories for the Sprint according to your Definition of Done by the end of the Sprint. During the Review meeting though, while demonstrating a story, you realise that there is something which doesn't behave the way the customer would want. Consider that the unexpected behaviour wasn't actually discussed together with the Product Owner before the Sprint start. You are all learning now that if you were the user of the product, you probably wouldn't accept it that way. Again it is not about finding out who is guilty for the mistake, but it is about refocusing and learning how to make it better next time. In this case though, the software functionality you produced is working, and what you probably will do is to add an additional story to the Product Backlog, which will specifically alter the undesired behaviour and improve the user experience. This is not necessarily to be considered re-work or bad work, it is the natural way to iterate and incrementally learn, by doing and failing as often and as fast as possible.
Handling defects is a pain. The pain increases the more we try to formalise a process to list them, qualify them, order them and ultimately plan them. A complex defect-handling process like this is plain waste. Rather than adding order to the chaos, it actually avoids facing and solving the problems that cause defects.
Instead, fix anything you can within the current Sprint, whether it's a defect or just a better idea - remember to share it with the Product Owner too.
If a defect or a change comes to mind during the Sprint, but without enough time to change it, simply create a Backlog Item for the change and move on. It's the Product Owner's decision whether to accept the item or not, but either way, the upcoming Backlog Item will make it better.
Always remember to think about these situations in the Retrospective and learn from them.
One last word of warning
Ultimately defects are bad, because they are difficult to handle: to reproduce and to fix. There isn't really a silver bullet process that would help you to optimally handle defects, but there are many things you can do to avoid producing them. The application of one of the extreme programming principles "writing tests first", combined with the practices of Test Driven Development (TDD) and Acceptance Test Driven Development (ATDD) can extremely improve the quality of the code produced. Most Agile teams come very rapidly to the understanding that working harder to improve the quality of the code is a long term investment with very high return.