What happens during the installation of Ubuntu
Let's solve this problem first:
don't really know what exactly happens during installation of ubuntu
Then I think you'll understand where you can be attacked.
The BIOS is stored on a flash chip. Typically we say rom on the motherboard but the truth is it's probably stored on an SPI flash rom and you can probably detach and flash it if you like.
Anyway, the CPU (your x86) will have its instruction pointer set to the reset vector on boot. After doing some initial magic, the code at the reset vector will load your BIOS from ROM then boot that.
What does the BIOS do?
The BIOS tries to normalize the system in an expected way such that it can provide a language for applications to speak and get things done in a platform independent way. This seems crazy at such a low level, but is actually the case.
As well as setting the system into a nice state for the rest of execution the BIOS can also talk to hardware. One of the steps it takes here is to look for option ROMs and load these.
Once it is done getting the system ready to boot, it must then decide what to boot. For hard disks, it understands how to parse the master boot record and will load a valid MBR to 0x0:7c00 and quite literally set the instruction pointer to the first instruction and say go. So the MBR is both executable code and a data structure describing the partition. Ahhhhh DOS. Thems was the days!
But you wanted to boot an ISO? No fear. Data disks are described by the el-torito specification, which allows an ISO to optionally contain a boot record with corresponding boot image code. As an aside, if you ever wondered why you can't find the [boot] file you see in 7Zip on the ISO itself, that's because it's kept outside the actual chosen file system of the disc in a different "record".
Anyway, the BIOS loads this too by it's usual put it in memory and set the eip to the start of it method.
Bootloader to kernel
The bootloader's job is to find a kernel and set the environment up in the right way for that kernel, then let the kernel get on with life. In the case of your Ubuntu ISO, this is likely grub which will search the disk for an appropriate, possibly pre-programmed-into-grub vmlinuz kernel - a compressed kernel image. I'll skip this step as it isn't very interesting but suffice to say the bootloader is likely running in protected mode with no paging and the kernel will go from here, probably switch the CPU into long mode (x64) and will certainly start talking to hardware essentially independently of the BIOS.
OK but how do I do something with my kernel?
the Linux kernel doesn't typically boot alone. You should never after all boot alone. Instead there is a ramdisk (initrd) present even on your machine which acts as a kind of temporary root file system providing basic support binaries. All of this is loaded into ram.
For the purposes of your install media, this probably also comprises the right software to set up the system or may even comprise an entire live distribution. When the kernel is ready it will find the "initial process", the first thing created in userland (you've heard of this - sysvinit, upstart, systemd are three examples) and run that. From there... you are in the land youu know.
How do installs function
Very briefly, once the system is up and running there is no reason it cannot read the CD-ROM. There's also no reason said CD-ROM cannot contain a repository of deb or rpm packages. With the right installer code you can partition the target hard disk and install each of those packages into the chroot.
Universally Sneaky Bus
So now you should have a vague feeling of knowing what your Linux install media is doing. Now let's talk USB.
USB is a host-device protocol. When you plug something in, the host plays 20 questions with the device asking it a myriad questions. Amongst the rounds of animal/vegetable/other are the questions "what device class are you?" and "who made you?"
USB device classes allow very common cases of USB hardware to talk in identical ways. You can think of USB as the transport (like say TCP/IP) and device classes as the application layer protocol (http, imap). This is just an analogy of course.
In the case of BadUSB, one of those devices, an endpoint in our network, is going to lie it's little heart out. It could do many things, but let's go back to the boot process above. At one stage the BIOS needs to do two things: parse the CD-ROM record data (ISO9660) and read the el-torito entries to get the boot code for the live cd.
Since BadUSB firmware tells lies, there is no reason that this step cannot replace the boot code with something malicious. From there, the malware simply needs to set hooks all the way up the boot process until it can run safely in the kernel. This is demonstrated in vbootkit2 (where the ISO boot image is already malicious, rather than being substituted by the firmware).
For your live CD, I'd think this is the biggest concern. Once the malware has a "bootkit" in your install, there is no reason it cannot alter the install process to persist, or otherwise drive the live install to attempt to infect your system further.
A keyboard-pretending device plugged in whilst your install took place would allow the keyboard to inject commands onto the system - I haven't looked at the Ubuntu install media for a while but there is usually a drop to terminal session. However, I'd suggest an attack like this would be even more complex than attacking the bootloader - with code you can detect and adapt to changes but with hard coded commands you are limited.
Of course, the practicality of all of this depends on storage space in the USB firmware device, since you're going to need to store sufficient binaries to at least bootstrap your malware from the network (or sufficient strings of characters to do it via a keyboard). Remember, to work you still have to do most things firmware usually does - such as drive the CD-rom in this case.
I am not personally familiar with the average space available to firmware on commodity external dvd drives... it could well be enough at the time of writing, but maybe not.
Am I at risk?
Probably not. While targeting the load address of the bootloader from CD or even hard disks is easy since it is known, knowing where to patch in the boot process versus the immeasurable number of linux distributions and kernels (and even bootloaders) out there makes this very tricky to implement except against specific, individual targets. That said it is not impossible.
The best example I know of a boot-based attack is vbootkit2(openoffice presentation link, Possibly NSFW: contains proof of concept for malware). In the downloadable code, vbootkit2 has a malicious boot sector on their live ISO that attacks the Windows kernel on your hard disk by patching each step of the boot sequence essentially as I describe above.