There is always an operating system, albeit not necessarily a complex one. The BIOS is an OS in the strict sense of the term: it provides access to hardware through an hardware-independent API. The boot code for an OS (or some malware that pretends to be that boot code) uses the BIOS-provided API to read (and possibly write) bytes from the hard disk.
Theoretically, nothing would prevent a piece of malware, installed as "boot code", to use the BIOS to observe the hard disks, locate "infectable" files, and infect them. This would imply making sense of the filesystem structure, which is normally a job performed by the "big" OS (the Windows or Linux or OS X or whatever). If the malware wants to do this by itself, then it must include the code to do so, which can be bulky, or take some non-negligible development effort. Thus, while it is possible, it can be expected that most malware authors, being no less lazy than any other developer, will prefer to avoid it. Booting a "normal" OS and then using its facilities to access files is easier.
The GNU GRUB bootloader is not at all malware; it is a piece of software whose job is to leverage the low-level disk accesses of the BIOS to locate and load in RAM the core elements of an operating system to boot (e.g. the kernel in the case of Linux). As part of its functioning, it includes support for many filesystems. A malware author who wants to locate and infect files in filesystem from a "bootloader" environment would probably reuse parts of GRUB. In any case, GRUB demonstrates that filesystem support code can be compact enough to fit in the constraints of the bootloading environment.