Thanks very much for coming to this talk. We are going to be looking at hacking and forensicating an Oracle database server. Although I just gave this talk at Black Hat, and I had an hour and a half to do it. I've just found out I've got 50 minutes. So I've had to slice some of the talk. So I think the boring forensic side can go, and the hacking side is the fun part, especially for this audience. So we'll concentrate on that. So who am I? If you're wondering who I am, I'm a vulnerability researcher. I started out in Buffer Overflow Exploitation. The last bit of work I did that I'm really proud of was back in 2003. That was defeating the stack-based protection built into Windows 2003 server. I then started moving into database security. If anyone remembers the SQL slammer worm, I was partly responsible for that, unfortunately. And when Oracle turned around and said their products were unbreakable, I laughed a little bit and did some research and proved it wasn't unbreakable by any stretch of the imagination. So I've been concentrating on the C&E side of things, or had been up until about 2007, 2008, and started looking to the forensic side because obviously it was so trivial to break into database servers and continue to this day to be trivial to break into database servers. Read Oracle. The whole idea of, well, if someone is breaking in, how do we find out what they did when they got there and what we can do to work out what we can do to prevent them from doing the same thing? So that led on to the forensic side. I recently, well, recently, a couple of years ago, I solved my company, so I get to do free stuff now. I have no commercial presses, which is great, so everything presented here is all the white papers are free, all the tools which I probably won't have time for, but you can go to the Verity website and download them. They're all free, there's no commercial version of it or anything like that. So if you want to follow my research, I can be found on d-litchfield on Twitter, or email me at davidatverity.com with a three for an E. So database breaches are common, much as a given these days, I don't think I need to convince many people here that databases are where the goodies are at. I recently did a survey on the Oracle L mailing list, which is like for DBAs and programmers and stuff like that. It's a fairly good list. And I asked who's doing checks on their logs, like security logs and so on. And only one third of DBAs are actually checking their stuff, and most of those are using grep. And I find that astonishing, because let's face it, grep's not going to work on binary-based B-spoke custom file formats that most databases have. Forensics seems to be this, or database forensics, specifically seems to be this no-man's land where the incident response people are saying, well, you know, I understand that I ask stuff really well, like analyzing hard drives and so on. But databases, well, that's this whole other extra stuff I need to learn.  And the database guys are like, whoa, I know all about how to improve the speed of a database and so on. But when it comes to IR stuff, yeah, that's way over my head, I'll stick to the stuff I know. So there seems to be this no-man's land where no one seems to be doing any work. And as a consequence, it lags behind on the forensics front. So getting to the good stuff, compromising the database. So in a typical database compromise, there are several stages. First off, there's gaining access, obviously. Once they've managed to gain access, they obviously then need to elevate privileges if they want to have full control of that database server. Once they've got the privileges, the requisite privileges to do whatever they want, they might want to modify data. They might want to exfiltrate data. There's a whole number of things that they want to do. And thereafter, they might want to use that database server as a staging platform to attack the rest of the network. So that might include breaking up the database to run operating system commands, and then download their toolkits, and so on. So we'll look at each of these sections individually. OK. So I've been playing with Oracle for 10 years, give or take a year or so. And yeah, it all started when Larry Ellison announced at his conference that Oracle was unbreakable.  And I was drinking red bull earlier, and I think that's why I'm speaking so fast as well. And I've got red bull in the brain, not red flags. So yeah, my brother and I did quite a bit of research. And my brother, Mark, found a really interesting floor. And this is, remember, an EAL4 plus certified products under the common criteria. And Mark found a floor, basically, where if you entered an overly long username, there was a stack-based buffer overflow, which was trivial to exploit. So a product which, under the common criteria, is supposedly secure could, in the authentication mechanism alone, be trivially compromised. And of course, that wasn't the only floor. There were a number of issues. Buffer overflows in the TNS listener. I'll explain in a minute. In fact, let's explain what the TNS listener is. OK. So you have the Oracle Database Server. The first port of call a client connects to is the TNS listener. The TNS listener is responsible for communication on the Oracle Database Server. This is really disconcerting, by the way. I can't see anyone's faces. So I also can see these bright lights. But anyway, the TNS listener is responsible for communication. So when a client connects to the TNS listener, it hands off the connection to the Oracle database process and communication takes place thereafter. Now, the TNS listener itself has had a number of buffer overflows in the past. So again, without a user ID and password, an attacker can exploit these to trivially gain control. But a much more interesting attack, one that doesn't require exploitation of buffer overflows, was a thing known as external procedures exploitation, XPROC. So I'll go into that very, very quickly. So let's say you're using the database normally, and you want to execute PLSQL code. PLSQL code is like the way you extend the Oracle database server and can execute stuff that basically allows business logic to take place and so on. Now, let's say PLSQL, which is a fairly substantial language, doesn't do what you require it to do. What you can do is write a we-see program, a we-see library, and hook that into the database server by using external procedures. Now, what happens is once we compile our library, we then tell the database server about it by doing a create library statement. And we wrap that library within a procedure, basically, which then calls the function within that library. Now, what happens is the Oracle process connects back to the TNS listener and says, will you load this library, execute this function, and pass it these parameters? And the TNS listener goes, well, I won't do it for you, but I'll tell you what. I know a program that will. And it launches this program called xproc and tells the Oracle process to connect to xproc. And xproc, sorry, the Oracle database process then says to xproc, load this library, execute this function, and pass it these parameters. And xproc goes and does that for it. Now, normally this happens over name pipes, but it turns out that you can use TCP as well, which is great, because me on the other side of the internet can connect to a TNS listener, providing, of course, the firewall allows access. And there are unfirewalled Oracle servers out there. And say to the TNS listener, I'm the Oracle process, wink, wink, nudge, nudge. Will you load this library for me? And the TNS listener sends back me a message over TCP and says no, but if you connect to this port, xproc will do it for you. So I then connect to that TCP port that xproc is now listening on. And then I say to xproc, hey, do me a favor, will you? Load this library, execute this function, and pass it these parameters. And xproc goes, yeah, no worries. And there you go. Without a user item password, we can load any library we want, execute any function and pass it any parameters. So of course, we could use load MSV, crt.dll, the Microsoft Visual C runtime, and execute the system function. Or if it's a Unix system, we could call libc and do exactly the same thing. So we now are running code as the user account that Oracle runs under. So on Windows, that's going to be a local system. Or Linux, it's going to be the Oracle user. Either way, as far as the database is concerned, you are God. So Oracle fixed that. And it's a really funny, yeah, it is actually funny, fix whereby they said, OK, what we're going to do now is limit where you can load libraries from. And any attempt to load a library outside of the designated place will log that, just so there's some forensics information there. And they did that by using Sprint F to pass the library name into a stack-based buffer. And anyone who programs and see here, and with a fixed size buffer on the stack without any length checking done, you immediately know, well, Sprint F is going to lead to a stack-based buffer overflow of vulnerability. So even though they limited where the library could be loaded from, or as I needed to do, to regain control without user ID and password, was exploit this new buffer overflow in the logging process. So Oracle, we were informed about that, and they fixed it by putting a length check before calling Sprint F. Why they didn't call SNPrintF, I don't know, but they decided to remain with the Sprint F. Now, it turns out that any environment variable names within the library name are expanded. But that's expanded after the length check now. So if I go $path, and let's face it, a path is maybe 200, 500 characters or something like that, suddenly we get to exploit this buffer overflow again. Just by going $path, $path, $path, we find the sweet spot, because to be honest, the path might be different on one system against another system. But when we find that sweet spot where the communication is just reset because the X-Proc dies, we can then move backwards, byte, byte, byte, byte, byte, overwrite the save return address. And we have an expression in the UK, Bob's your uncle, I don't know if you've got it over here. Bob's your uncle, you own the process again. So yeah, the thing is, even to this day, if you are local to an Oracle database server, in other words, let's say you've got SSH access, if you're local, you can still do this trick locally to get code to run as someone else. So 10 years after the fact, we can still do this Oh, and incidentally, of course, if UTL TCP is available, once we're connected to the database server as a privileged user, we can use UTL TCP to create the right packets. And because we're now suddenly local, so from the Oracle process, we are communicating directly with the listener and X-Proc. So again, we can still affect this kind of attack. And today, Oracle is still vulnerable to this kind of thing. Now, one would think that dropping msvcrt.dll in the directory where Oracle allows you to load libraries from is a bad idea, right? Well, guess what's in there? It should be in the Windows System 32 directory, but for some reason, they thought, well, we don't want it in there as well. Sorry, we need it in the Oracle Home directory, in the Bin directory. So they make all these fixes to prevent you from calling the system function in msvcrt.dll. But they go ahead and then dump the DLL in the same directory. So it's all for naught. So I really don't understand what kind of security questions are being asked at that organization. Like, we're about to do this. Is it a good idea? If not, let's not do it and find another solution. That's the minimum kind of security question that should be going on. And it's clearly not going on as far as I'm concerned. So anyway, there's a whole bunch of ways that we can use to gain access without a user ID and password. And of course, Oracle is one of these great database servers that has, depending upon the applications you install, a number of default accounts with default user IDs and passwords installed. Now, this has changed. Obviously, in 10G, you now have to set a username and password, sorry, the password for the key accounts, sys, sysman, db and smp, and sorry, sysman, system, db and smp during the install process. Whilst you're installing, though, the default passwords are in place. So sys has a passwords of change on install by default. But during the installation of the Oracle server, the password is still change on install. So if you can find someone installing Oracle at that particular moment, you can obviously still connect as sys with the password of change on install and do unifary stuff whilst the server's being installed. Obviously, you have to hit the moment right. It's probably never going to happen in the real world. It's just one of those things you observe in the background. But there's a whole bunch of accounts out there that are typically locked but still have a default password in place. And you'll find in the wild there are instances of servers out there with a db and smp still with its db and smp password. ctxys still has its password of ctxys. In fact, there are about 600 to 700 accounts, depending upon what products have been installed with default usernames and passwords. So even if you can't exploit any buffer overflows, trying a username with the username as its password is a good guess. And so yeah, there's a whole number of weak passwords and account compromises available. And if we have access to the file system, what you'll find is that the passwords are often logged. They're encrypted, but they can be decrypted because we know what the keys are. On the file system, there are certain log files where we can snuff the passwords out. And they're world readable, of course, as well. And so yeah, even if we don't have a user ID and password and we have local access to the box, we can still gain access by snuffing these passwords. And of course, if we're dealing with a web-based application, then we can just piggyback. If it's vulnerable to SQL injection, we can just piggyback the whole account authorization process. Sorry, authentication process is handled for us by the application. So we just piggyback out our SQL injection off the back of it. OK, so assuming we get access, I'm just going to create an account, create user defcon identified by password. Great, quit. So I'm going to give this defcon user a grant create session, rather, to defcon. The only privilege required to connect to the database server is create session. I'm then going to connect as this guy. I create defcon password. OK, so this is the account we're going to use to run out nefarious stuff, select staff from session privs, we'll see. That's all he's got. OK, create session. So basically, this user, the only privilege he's been granted directly is the create session privilege. So he can connect to the database server, and he can't do anything himself from here on in. But there's a special user account called public, which means everyone on the database server, essentially. So whatever public can do, defcon user can do as well. Now, I spoke about PLSQL earlier on it when I was referencing external procedures. The default security mechanism for executing PLSQL objects such as procedures, packages, and functions, and so on is the definer's privileges are used to execute the object. So if the sys user creates a PLSQL package, he is the definer. Any vulnerabilities in that, as the definer, will execute with sys privileges. That's the default. You can also specify, using the auth ID keyword, the current user's privileges should be used. But by default, it's the definer's privileges. So any package which is owned by a highly privileged user and is vulnerable to PLSQL injection can be abused by an attacker to gain full control. Well, not full controlled. It depends on who owns the package. But in the case of sys, sys has all the privileges that's required. So yeah, if sys owns a vulnerable package, then an attacker with only great sys and privileges can exploit this floor to gain full control of the database server. Now, Oracle has probably had about three to 400 such issues found in sys-owned packages. So we're not just talking about a one and two case scenario kind of thing. This is the achilles floor in the Oracle database server and continues to be. So every three months, Oracle releases a critical patch update. Sometimes they fix five critical floors. Sometimes 20 to 30 critical floors. More often than not, there are at least one or two, if not more, PLSQL injection vulnerabilities in Oracle. So I'm going to show you a fake one because I don't want to put, I'm just going to show you one that I made. So if you want real ones, look at the critical patch update from last time. Or if you want a brand spanking new one, wait for the next one to critical patch update to come out. They're too penny these kind of floors. So as an attacker, let's say, remember, we only have the crate session privileges. If we wanted to do things like delete the audit trail, we obviously need the privileges to do that. We can use these SQL injection floors in high privileged packages to do things like that. Or we might alternatively just say, grant ourselves DBA. Now that would be a very noisy thing to do, obviously, in a real world attack. And you probably wouldn't want to do that. So what you might find is people inserting directly into the SysOrth table, which essentially does the same thing as the DDL statement for grant DBA. But it uses an insert instead to grant those privileges. And even then, all of this kind of stuff is making noise, and probably won't be done. But for the sake of argument, it's a nice demonstration here. So let's do it. So there was a nice little attack previously, or a way of facilitating attack, where we could generate our own cursor that we would pass our nefarious SQL on. And we would inject the dbms underscore sql.execute function into the vulnerable procedure, and that would go ahead and execute with the higher privileges. So whatever SQL we pass, be it grant DBA, would execute with the higher privileges. But Oracle went ahead and fixed that. So what we need now is another way of looking for ways of running arbitrary SQL. With Microsoft SQL server, you can batch SQL statements. So you can just do a select, then an insert, then a grant, and a crate, whatever you want, one after the other in any kind of SQL injection situation. With Oracle, you can't batch statements. So if we wanted to say something like grant DBA to public, and it's in the middle of a select statement, that's where the vulnerable, actually, let's talk about that quickly. Here's the sample that we're going to use. Can everyone see that at the back? Is the font big enough? Yeah, it should be. So all we're doing is the procedure owned by Sys, in this case, I've called it Vonprock. And it takes the user input str and concatenates it into this query select object name from all objects where owner equals user input, and then executes that query. Now this here is an example of PL SQL injection. But because it's a select statement, we're injecting into a select statement, we would be limited to, without an additional hack, we'd be limited to doing another select statement, like a union select, or something like that. But that doesn't get us DBA privileges. So what we need to do is work out another way of doing that. So we have our auxiliary inject function. In this case, it's the new context function on the dbms underscore xmalquery package. Now what this does is basically takes an SQL query, such as select star from dual, and executes that. But it doesn't have to be a select statement. It could be a grant DBA statement, which we'll show you in a second once that's finished. I've just freshly started the Oracle database service. So things need to load into memory. Right, great. That's it done. And that will return very well. So now we're going to use this to exploit the floor. And let me put a sys in front of that. So before doing that, let's show you it's vulnerable to SQL injection. So we're going to execute foo. That's how you would execute it normally. So what would happen is foo would be placed into str. And the query would execute. If I put a single query in there, we see SQL command not properly ended. So that's indicative of a SQL injection floor. Go minus minus. And that minus minus basically chops off the rest of the statement. And yeah, so we're all good there. So now we can go ahead and exploit that to gain, did you? Sorry, I thought someone said something behind my back. There was a ghost or something. Lost my train of thought. Right, if I do set role DBA, first off, you'll see we've not been given the DBA role. DBA role hasn't been granted or does not exist. So now we're going to gain DBA privileges. So what we've done there is injected. This is our little trick, by the way. Remember I said, if we're in a select statement, we can't do anything other than a union select or whatever, or a sub-select. Well, this declare pragma autonomous transaction basically tells the PL SQL compiler, this query is fine to execute on its own. It's its own transaction. Go ahead, everything will be safe. Now, as a consequence, we can execute arbitrary PL SQL. And in this case, it's begin, execute immediate, grant DBA to public, and we end that. And we get the message it's successfully completed. So if we go set role DBA now, DBA, role has been set. And if we do select staff from session privileges. Honestly, it's so easy to break into our Oracle, you don't need to applaud me on that. Select staff from session. But thank you. It is appreciated. I'm here all week. Try the steak. So we've now got all these session privileges. So we've gone from create session only through to exploiting a PL SQL injection flaw, which there are three to 400 of, depending upon the version of Oracle that you're looking at. And suddenly, we're gone, as far as this database is concerned. So now I'm going to do auto user sys identified by password. So I'm now changing the password for the sys user. And as you'll see in a minute, logging in as sys is going to give us some fun stuff. Connect sys password at rcl as sys DBA. OK. So we're now connected as the sys user. We're going to start playing with a thing called already bug, which is a nice little facility that allows us to read from the Oracle Process Memory right to the Oracle Process Memory, and also execute arbitrary functions and so on. So let's, before we do that, yeah, breaking out of the database, how are we doing for time? We're doing OK. Great. Breaking out of the database, running arbitrary code. Well, obviously, if there are buffer overflows, and again, maybe each CPU, one buffer overflow, sometimes there's zero buffer overflows being fixed. But actually, I think there's at least one or more being fixed in every critical patch update. Sometimes there's lots. Yeah, sometimes they get a slew of flaws coming in. But we're specifically going to look at the already bug stuff here. Now, what already bug does is, basically, as I said, it allows us to peek and poke at memory or debug. Already bug has been documented before, by the way. So this is nothing new. People have been speaking about using already debug as a hacking facility for a long, long time. So yeah, this isn't like Odey I'm dropping by any stretch of the imagination. So if I go already debug help. So here's the help options. Some of them are very interesting. Some of them are not so interesting. But we're going to be looking at these two, peek and poke, and call, which basically takes a function name, and you can call that function. So here's one I made earlier. OK, so first off, we need to set the process ID we want to debug, and we're just going to use the process ID of my given process. So set myPID. So one of the great things about already bug, well, let me rephrase that. It's bad that we can do this with already bug. But one of the good things thereafter is any time you use already bug, a trace file is created. cd dr, actually find str, forward slash i, forward slash c, already bug. I just want to find the current slash od. 628. OK, so this is current one type. So we can see, remember the first already bug command I should was help? That's written to this trace file. And then I did set my PID and so on. That's written to the trace file. So any time you use already bug, it's being written to a trace file, which is great when it comes to forensics. So what we're going to do here is we're going to run an operating system command. Because remember on Windows, Oracle runs as the local system user. So any arbitrary code I execute is going to execute with the privileges of the local system user. And in this case, I'm going to create a user account called or a hack with a password of pwd and add it. And I'm going to call the system function. So what I'm going to do first is write to this memory address four bytes, which is net space. So that's the net space of the net user add command. And then so all this here is basically net user add pwd slash sorry, net user or a hack pwd slash add. And I'm going to write that into memory. And you can see here I increment the address obviously by four. Because if I didn't do that, obviously we just overwrite the same bit of memory. So what you'll see here, let's clear the screen. So oh, don't do that to me. Give me two secs. Because I restarted the system, the memory's gone. So I'm just going to fudge one. We can do this, by the way, again, using or a debug. We can dump a stack trace. And then using utl file, we can read that in. But I'm just going to cheat because that takes a wee bit longer, 3, 4, 3, 7, 2. VADump, minus p, 4, 3, 7, 2. OK, pick one at random. OK, we don't need execute read write. We just need read write. Reserve, that will do. 1, E, 2, 3. Edit, bind, replace. 1, DDF, bling, replace all. OK, home and control C. Right, let's try this again. OK, great. So what we've done there is written the net space part. So let's add the rest of it. So I now have written in memory the net user or a hack pwd slash add. That's the operating system command I want to execute. Now I basically call the system function here and pass to it the address at which can be found the operating system command, the net user add stuff. So before I do that, if I go net user, whoops, net user, we can see I've got VMware user administrator David and guest. There's no or a hack account right now. But I'm going to get Oracle to now create the user by calling the system function return zero as it should do. So net user now shows us we've got this or a hack account in there. So thank you. So what we've done is from a lowly create session privileged user account, jump privileges to DBA, change the sys password. And now we're connected to sys. We can then start poking and peeking into memory and running arbitrary functions. Now of course, we're only limited by our imagination in terms of what we want to do as far as executing arbitrary code is concerned. We could use this to send us back a reverse shell or anything we want. We just obviously need to create the right structures and memory, get the right addresses, and send them to the function basically. And one of the great things, of course, is when you call a function, the value, the return value, whatever is returned in EX, is basically dumped in here. So if we call the socket function, we can get the socket handle by looking at whatever the function returns and so on in there. OK, and then we can then add that in and so on. But I think the key takeaway from there is every time you use our debug, it's in that trace file. So what we can do is look in that trace file. You can see the stuff I've written to memory I can now extract. And then as a forensic investigator, I can go ahead and start working out what the attacker attempted to do. So if they indeed try to spawner of our shell or something like that, their code is going to be in memory, not in memory, in this trace file. So we can build up a very good picture, so anything they're doing is in there. But you do have to remember, of course, that we're connected as sys. We, as far as that database is concerned, we are God. So if we wanted to, we could delete that trace file. Suffice it to say, though, if they don't delete the trace file, it's a wonderful source of information. And of course, we can run operating system commands in other ways. We spoke about external procedures earlier. Let's do that. First off, I'm going to do one that will fail. And the reason I'm doing that is because I want to show you another useful bit of information. Remember, I said it was logged. The name of the library is logged. That's actually Ron Prokman in the back now. Because I've just specified MSVCRT.jl. I haven't specified a path or anything like that. It will look through the system path for the right DLL and decide that it's not in the right location. It's not in the Oracle home. So we'll get a message being logged saying that it's an invalid DLL path. So remember, I said you have to wrap it. This bit of code at the bottom wraps the call. So let's create that. And remember that this is going to fail when I execute the function. So and we'll get the invalid DLL path. But if we look here, HS. OK, we can see in there someone tried to load MSVCRT.jl. And it was sys. And the library name was this and everything like that. So again, useful forensics information worth looking at that directory. But let's make it work now. Remember, I said they dropped MSVCRT.jl in the bin directory in Oracle home. So we can now go ahead and recreate that. If I do net user, we've got the Oracle hack user. We're now going to create our hack to the password. So we get that successfully and net user. We've now got the our hack to user in there and so on. So dropping MSVCRT.jl in there wasn't a smart idea. But to be fair, if you think about it, watch this. CD backslash at CD bin. OK, this is the Oracle home directory. That's all attack surface. These are in there by default. Any function on there, we can obviously call. And if they are susceptible to things like overflow or whatever, then we can still use this external library thing. What Oracle should do is have an area where there are no DLLs by default. There are no code objects by default. And if you want to add your own stuff, you can put it in there. Having it as the Oracle home is too lax as far as I'm concerned. So yeah, all of this is attack surface, basically, from an external procedure point of view. So yeah, it should be tightened up considerably. We're doing time. OK, OK. So I've really run through the hacking side of things. So we've got a couple more minutes left for a wee bit of the forensic side. So the database has been breached. And what do we do now? Where is the evidence? With Oracle, the evidence is everywhere. It's great. There's so much redundancy built into the Oracle database server. It's wonderful. Security, not so wonderful. If we look at Microsoft SQL Server, SQL Server 2005 I think has had three critical patches required since 2005. So what? That's pushing six years. And it's had three critical patches. Microsoft SQL Server 2008 I think has had zero. If we look at Oracle, each every three months, patches are coming out time and time again. As I said, sometimes they're patching up to 20 to 30 issues. Sometimes it's only five or six. But every three months, you have to worry about Oracle security all the time. But every three months, it's patch day.  Obviously, you've got the transaction log and you've got the error log file. But as far as useful information goes, that's pretty much it. Oracle is great. It's wonderful. So let's look at some of these locations. So obviously, the system metadata itself, the information that makes up the database server is a wonderful source of information. The data files, when a record is updated or deleted, the data is left intact. It's just, well, each row of data has a three-byte header. How are we doing? OK. Each row of data has a three-byte header. The first byte of that three-byte header has its flags, basically. And the fifth bit, if you flip that bit, it says it's deleted. If you flip it again, it says it's not deleted. So we can very, very quickly find deleted data by looking at that first bit of the three-byte header to say, is the bit set or on set and whether it's deleted or not. So if you delete data, if you think, I'm hiding my tracks, so I've deleted all my stuff and everything like that, it's still in there, it's just that bit's been flipped. Or if you update data, that bit is flipped and everything and a new row is created. So it's really useful when it comes to that information. There's a thing called the active session history. I wrote a couple of papers on this a few years ago. So what active session history is, when the Oracle server is running, there's a sub-process running in the background, basically polling the database server every three seconds to find out what's going on at that particular time. It takes a snapshot. These snapshots are recorded in memory. And then every half hour or so, one in 10 of the snapshots are recorded on disk, basically. So if you have a query that lasts for, say, three seconds, you're going to have a snapshot in it, definitely in memory somewhere. If the query lasts for more than 30 seconds, chances are there's going to be a snapshot written to the disk. So this active session history becomes a really useful source of information for looking at select attacks. Select attacks, obviously, are just getting access to data. So if you're downloading a customer database that, say, has five million records, that's going to take longer than 30 seconds, probably. If you're using something like UTL HTTP or UTL Intdra to exfiltrate data over an out-of-band method across the network, that's going to take a long time. And so there will be calls to these SQL statements will be logged in the active session history. And as a forensic investigator, we can go back and look for evidence of even select attacks. The transaction logs, like the redo logs in Oracle, anything that requires a transaction is logged in the redo log. So that's another great source of information. So that's things like deletes, inserts updates, select for updates, any DDL, like grant crates, and drops, and so on. All that information can be found in the transaction logs. Undo segments, if you make a change, an undo segment is created that has information pertaining to that change. So again, we can query that. The memory itself, in a live response situation, we can start querying certain key tables for a key virtual views, rather, for information. So one of them is VDAR SQL. It has about 3,000 to 5,000 queries that have the most recent ones that have been executed. So if we can find an attack in progress or an attack which happened just like half an hour ago on a fairly quiet database server, there might be evidence of attacks in there. VDAR DB object cache is another great source of information. So again, a couple of years ago, I wrote a paper on hacking the Java virtual machine built into Oracle and looking through the source code of the default Java objects, there's this UTL wrapper that basically takes user input and passes it to the system function, basically. So if there is no reference to this UTL wrapper anywhere else in the Oracle code, and I think it's left over there from development days, so no real world code should be using it. So if it's in, if it exists in this DB object cache, one can infer from that that an attack has probably taken place. So again, there's these virtual tables which are a wonderful source of information. And obviously, the log files themselves, like the TNS listener log file, is the first port of call. Any kind of connection is going to be logged in there. Caviar emptor, though, when it comes to the TNS listener log files, when a client connects, they pass the program name and stuff like that, and that's all logged in the TNS listener. But because it's under the control of the client, they could say whatever they wanted. They could pretend to be a JDBC client, whereas in actual fact, they're a C hacking tool. So don't fully trust the information in there. Use it for pattern recognition and so on, perhaps. Or another one, for example, when you authenticate to Oracle, what happens is you connect to the TNS listener, the TNS listener, OK, great. The TNS listener then passes you off to the Oracle process and you authenticate or attempt to authenticate. And if authentication fails, the client tears down the connection and you start the whole process again, connect to the listener. The listener passes you off to Oracle and so on. Now, as a consequence of the client being the one responsible for tearing down that session, if we don't choose to, if we fail authentication and we don't choose to tear down that session, we can continue to authenticate once we've got that connection to the Oracle process. So we can make one connection to the TNS listener, which passes off to the Oracle server. We then say to the Oracle server, is the password for sys this? And if the Oracle server says, no, no, that's not the password, we don't tear down the connection. We just say to it, well, how's this for a password for sys? And we keep on firing multiple attempts down the same TCP pipe so we're not having to go through that whole setting up the communication again. So what would take typically a minute to go through a couple of hundred passwords? We can go through a couple of hundred passwords in a second so we speed up brute forcing. Obviously, later versions of Oracle account locking is enabled by default, so we would just go for the sys account because you can't lock out that account anyway. And obviously, the trace files, we looked at ROD bug earlier. I'm not going to have time to show you any of the tools and stuff. If you are interested in the tools, they're free. Go to the Verity website, download them, play with them, have fun, and everything like that. So thanks for listening. Are there any questions before I disappear? I can barely see you. So if you do have a question, shout out. OK, no questions then? Great. Thank you very, very much for coming. Thank you. Thank you.


Growing up in the middle of Australia was beautiful and I love the outback, but sometimes it can be challenging and I had a lot of self-doubt. I thought attending university was impossible. I thought that going overseas was impossible. I felt a little bit isolated. I knew that I needed to go to university to have an interesting job. I wasn't satisfied or challenged in the work that I had. I made that decision to move across the country and go to Griffith. Going from being convinced that you are not smart enough to go to university at all, fast-forwarding 10 years and you're standing on the stage top of your class with the university medal.  Griffith helped me to become brave, brave enough to be myself in any situation, to be authentic and to find my place in the world no matter where I am. The Minister for Foreign Affairs, she referred to me in a speech last year and she said that I would make a fabulous employee. So it was a very exciting week for me because I was also offered a graduate position in the Department of Treasury and Finance here in the Northern Territory and that was a really exciting time for me because I was able to analyse projects and initiatives that I know will have a direct impact on Alice Springs and my family. When I was a child I was too scared to dream about my future. I didn't put any thought into it because I was scared that whatever I wanted wouldn't happen. But now with quality education and heaps of experiences that were really deep and meaningful, I have a lot of confidence that my future is going to be really bright.


My name is Mubara Kabdala and I'm the camp coordinator of Mombasa Mango Forest in Mombasa County, Kenya. We will be planting hash of a kado in this area.


Hello, and welcome to the Jenkins documentation office hours today is April 27, 2023, and it is the EU US edition. Today we have myself, Mark Waite, and Bruno Verrachton. And if anyone else comes in, we'll welcome them, as we always do, on the agenda today. I have an update for Google Summer of Code. The announcement is going to be coming next week, so just want to make sure everyone's aware. Recently, Alex Brandes has submitted a full request to potentially revise community feedback, so I wanted to discuss that here. LTS 2.387.3 is going to be coming out next Wednesday. The next LTS baseline is being discussed. There were some Java updates recently within the last couple of weeks for the various Java versions that we're using right now. So 11, 17, 20. CDCon is coming up, so just quick note on that. Reminder and some discussion around the plan to transition the documentation from using Java 11 to 17. Note for the success stories link that we now have, there is an update to XML handling for null characters, so that's something that we'll talk about and that's going to be coming up in weeklies and LTS eventually. One of the discussions we've been having is alternate ways to handle stale documentation pull requests. So we've made some headway and got some actions done there, so update from that. Mark's been getting a lot more information and data for the end of life notifications in Jenkins Core, so lots of great, great conversations and feedback happening. So we've got everything listed out here and we'll talk more about that. And then finally, as we've been discussing, the end of life for CentOS 7 in the Jenkins project. Anything else that we want to make sure is on the agenda today or anything else that anyone wants to know? No? That all right, thank you very much. So first things first, Google Summer Code is vastly approaching. Google is going to be announcing the accepted contributors on May 4th, so next Thursday. And then May 5th, we're going to have, the Jenkins project will have office hours dedicated to welcome those accepted applicants. So keep an eye out for that announcement. And we'll also have follow-up posts, tweets, LinkedIn posts about this. So even if you don't see it in one place, you're sure to see it somewhere. And just a nice welcome back to Yiming Gong, who is returning after being a contributor last year. This year, they're returning as they're coming back as a mentor. So really excited to have that return. And thanks for joining the project and the, all the, yeah, thanks for joining the project. The next thing on the agenda is this poll request that, like I had mentioned, Alexander Brandis has submitted about potentially revising community feedback. Now this is specifically feedback for the changelog. So right now, there is a straightforward way for people to say they're either having a great time with the release, having a time, and having a horrible time. So they're very simple measurements. It's just numbers and kind of a status. They do give the option to provide a JIRA ID when someone clicks on it. But Alex had pointed out a lot of things that doesn't necessarily always happen. It's hard to action on those things. If there's no trail or person or contact, it's not necessarily beneficial to the developers and people working on this as it's harder to really, really pin down what's going on and what's happening. And so we've been discussing this a little bit further. And I think it's worth examining this and taking a look at. But I think personally that there's ways we can use these to our advantage as opposed to potentially just having them be a counter, essentially. So I've questioned whether or not we could actually use these as a means to get someone into the creating a ticket window. Or if they're saying they have to roll back, I was thinking maybe we could have it redirect to the JIRA issue tracker where they could create the ticket instead of asking them to provide the JIRA ID number, recognizing that that could end up in a lot of unnecessary tickets. And I don't want to overload anyone's system in that sort of regard. But that might having more information in this case might be OK because if it's all related to the same issue or if multiple people are reporting the same thing, they can all be linked together and potentially have those extra ones closed out in favor of one. But again, that's a very different view. And yeah, I'm not sure what the final result will be, but I'm just wondering if there's ways to use these to our advantage as opposed to just removing them outright, for instance. Yeah. And my preference is not to remove them. There have been a number of discussions about ways to improve them, but nobody willing to do the implementation work to implement the improvements. And I'm hesitant to lose the data that we're gathering right now to not have that in the future. We don't have anyone who's committed to do a replacement for these, right? The rating system, if you scroll down a little bit, Kevin, you'll see, for instance, sometimes there's Jenkins-420 that's submitted or Jenkins-1.  The complexity there is that we just don't know in the context of this page if what they're submitting is a useful reference or not, saying, oh, it's a closed bug report actually doesn't help it. Because if it's a closed bug report, but it really caused them to roll back, that's a valid thing. If it's a non-existing bug report, okay, that might be, but it's easy to choose novel numbers that are existing bug reports that are irrelevant. Two, three, those are probably real bugs, but they didn't actually affect 2.375.1 in any way. Right. And more than likely they'd been closed for some time if it's going to be one or two, something like that. Absolutely. Since I know we're up to 70 something thousand, but yeah, but yeah, and I definitely don't want to take that stuff away as a matter of what could come across as seeming less transparency or just less insight. I think it's, even if it's not the most valuable thing, it's nice to have just so people can take a cursory look while they're going through the change log to see, oh, some other people are having issues. I should be careful or look out for it. It might just be enough to signal that in someone's head, so. Great. Yeah, Bruno, any opinion from you? No, I only discovered these weather icons a few months ago. I don't know. I think they are quite useful at they are, and you're right. Giving more freedom to the end user to declare new Jenkins JIRA issues or referring to non-existing bugs doesn't really make sense. I don't know how we should omit that, but I'll keep an eye on your discussion. Kevin, Mark, Alexander and so on, because maybe something good will come from that discussion. It's good as it is. It could be better, but I have no idea how better could be implemented. Thanks for asking. So Kevin, if you open the weekly, we can see on already on page one above the fold, we can see to an example of a very useful use. And last week, so you see under 2.402, 7.1156 is actually a very important. Oh, we've got a regression there and that that one really matters. I understand why they rolled back given this description. So so this one very, very good. Now, if you go back to the page, you'll see the release prior had three reports of rollback and at least one of them said Jenkins dash one, which is nonsense. But how can we screen between nonsense? No, we can't. OK, I think I think you said it exactly. We can't. We there isn't there is other than the human screening that we do right now. And and given that the human beings who look at this are looking at it for answers to the question, shall we consider this as an LTS baseline? And I confess, I use that in my prepping an email that says, I think we should use 2.401 as LTS baseline. That email was inspired by the fact that, hey, there weren't any credible reported rollbacks for 2.401. Yeah, makes sense. Yeah, just looking at it from that level, makes total sense, Mark. Yeah. And and all I if if it hasn't resolved itself, I plan to discuss it further with Alex Brandus at CDCon May 8th and 9th, because he and I will both be in Vancouver. And Gavin Mogan, if he if he's there is also one who's been involved in the discussion about ratings. Mm hmm. So you don't have to be logged in or whatever to click on that. Anybody is free to click. Yeah, so even a boss could, yeah, whatever. Yeah, exactly. Thank you, Mark and Bruno for sharing. Appreciate it. I'm glad we're having this conversation and I will continue. So yeah, anything else before I move on from here? Is that OK? Cool. So next thing up. So we have our next LTS release is coming on May 3rd. It will be 2.387.3. So the RC, the RC candidate, everything's ready to go. Testing is available. Change log and upgrade guide are been added and submitted. All we're waiting for is the approval, the final approval and merge on that. And we'll be good to go. And then as Mark had shared, we have also started the discussion for the next LTS baseline. Right now, the highest voted suggestion is 2.401. As Mark said, there were no real credible threats of rollback or anything that was reported, so it seems like a good baseline to work from. And yeah, it does have support from others as well. So if you have any strong feelings one way or the other, please check in on the mailing list and share. Next up, there were recently some updates for various Java versions from Timurin, OpenJDK and Oracle. We've put the Timurin ones here as they're the most reliable and most used in as far as Jenkins goes. And just they have 11.0.19. This is that latest release, the 19th. It's got notes and there are. Yeah, this is something that everyone should just be aware of and make sure they're doing. Mark, is there anything specific for the update or why people need to be aware of the update? So there were security fixes in each of those. I'm not aware of anything that specifically motivates you. You absolutely must upgrade immediately, but upgrading to get security fixes is a good thing. OK, perfect. So it's just a recommendation for our users. If they want to, they can upgrade to those versions, but there is nothing yet in the documentation indicating that people should use Timurin and these versions of Timurin, am I right? Well, actually, the documentation does describe that the Jenkins project prefers Timurin. Now, OK, it's a few months ago. My my understanding, I think that pull request has merged. It's worth checking just to be sure. But but there was a there was an addition which was trying to describe to people that the Jenkins project prefers Timurin. And and, of course, our container images are using these latest versions already, right? So shortly after the versions were, oh, I think they are. Now I I'm not so sure. Yeah, I think I saw the PR for the 11.0.18, but don't know about the 19. Yeah, let me check because I need to check to see if they if Timurin has updated the Yeah, as updated their image for us. Good question. And my next question, which is linked, is is there some part of automation in the documentation website to reflect the new versions of the Timurin bills? Thankfully, not needed because we don't refer to specific version numbers of the Timurin bills. So so we and we like that. OK, so Eclipse has issued <IP_ADDRESS> container images. For yes, so so it's possible now for us to do the upgrade. It wasn't a relatively few days ago, so we're going to need a pull request to our Docker containers. Great, thank you about that. Thanks very much, Bruno. Thanks, Mark. Next up, so CVCon is approaching. It's going to be May 8th and 9th. That's where the Jenkins awards will be provided to the winners and among the other CDF awards that will be presented there. So if you haven't already signed up or registered, there's I think there's still time to do so and get over there. So if you're going to be there, come by, stop, say, hey, Mark's going to be there, as he said. Alex Brandes will be there. Gavin Mogan will be close enough that he might show up. But otherwise, people will be there to represent Jenkins and share and talk. So by all means, come on over. There's also going to be a handful of sessions regarding CDCI and Jenkins. So we have a recent blog post that just outlines a couple of those providing some information. So one from Fidelity, one from one regarding Jenkins and other releases. So there and Mark's getting well, Mark's going to be participating in two sessions. So really exciting to have that. So thank you, Mark, for representing next up. So right now we've been talking and discussing the transition for the documentation to move from Java 11 to Java 17 for things like installation instructions and other hardware software requirements. We're not dropping Java 11. We're just transitioning to Java 17. It's got a longer life right now, has more functionality, faster testing and just provides overall better development resources for anyone using it. So I've created a GitHub issue that is that contains the various pages that I found where this transition should be looked at and potentially happen. It's mostly, like I said, mostly installation. The Java upgrade instructions also need to be changed because right now it's talking about the move from Java 8 to 11. So that will have to be updated as well. But this is a result of the Debian 12 release that's approaching. Not sure exactly when that will happen, but it will not be delivered with Java JDK 11. So this is in advance of having to worry about that across the board. We can get ahead of it and we can start using 17 as a recommended option. We may hopefully get people to migrate over sooner than later and that way have less to worry about when it does come time for end of life for Java 11. We're not dropping Java 11 support at all. It's Java 17 is also available for full functionality and we want to get people on that. So more to come on that once I start getting into the transition. We'll provide more updates here. One of the other things that I wanted to note is that we recently have the success stories in the stories site as a navigation link now in the top nav bar here on Jenkins.io. So thanks to Gavin Mogan and Alex Prenis for getting that set up and working. So now we have this really nice success stories link at the top of every Jenkins page so that the stories page is highlighted and available. That's cool. What is a process for a user to post a success story? So as far as I can recall, there was a Google form originally but now it's submitting a pull request. OK. And there is a stories repository specifically for those pull requests. Got it. So Kevin, I think if you go back to the top level page. Yeah, we should be able to see. Oh, maybe not. OK, so I thought there was a there was a link there that gave us obviously not that told us where to find how to submit a new story. So click read user stories. Yes, there it is. Submit a pull request about your goals and challenges. There it is. Yep. Yeah, and I think I think if anything, it just needs to be updated to have like a link to the correct repository to submit the pull request so I can take care of that problem. Well, or scroll to the bottom of the page and let's see if it's got an improved this page link. Nope. OK, yes. So then that that should be a hyperlink. OK, cool. I'll go ahead and I'll submit a pull request for that after our office hours is over. Thank you. Great. Next thing on the agenda that I wanted to bring to everyone with attention is that there was a recent update for how XML is handled in Jenkins. Specifically with the use of the JUnit plugin. So as it was before, ASCII null characters could be both written and read fully without any issue. The recent change from the KXML2 driver to standard sex driver has made it so that while the null can be written, it cannot be read. So if this is something that you run into or are experiencing, you do need to update to the newest version of the JUnit plugin. It was just pushed a couple days ago or in within the last week, regardless. So this is a very, very recent change. It's going to be part of weeklies going forward. It did not make it into the 2.387.3 LTS. So it will not be part of that, but this will be in effect going forward. So it is best to update everything now and take care of it. So there are just so everybody's clear. Null is illegal in XML 1.1 as a data value. It's simply illegal. So we were writing illegal data and reading illegal data. And now we've we've switched with the upgrade of this reader so that we will we will we now have the ability to write but not read. And now it's with the change to the JUnit plugin, which was the one thing we knew of that was writing null bytes. It no longer writes nulls. So will there be a period of transition when people will get some errors because of the read of the null and then they will modify their dependencies and then it will not be a problem anymore. Yeah, so if you're running if you were running a Jenkins weekly or prior to this prior to the core change, which is 2.402 and earlier or a Jenkins LTS and you're running an older version of the JUnit plugin, it will it will give you if I remember, it gives you an error message that says, hey, I can't read this file. OK, but if you have a recent version of Jenkins and the list of plugins updated, you won't face this. Correct, correct. So by by current version plus current Jenkins core plus current JUnit plugin, you will not see an issue. So I won't see that. Right, thank you. Exactly. It's only if you're running an outdated, outdated version that you could see it. Thank you, Mark, for adding in the context there. And there are actually both a GitHub issue and JIRA issue for this. So I'll be sure to add those into the document agenda just to make sure that those are available for for contacts and historical purposes. Next step. So we have five minutes or so left. I want to be conscious of everyone's time. So we've been discussing alternate ways to handle stale documentation pull requests in Jenkins.io. So we've been discussing if it's stale and not valuable. We close it. If it is valuable, however, we want to make sure that that information and that work is not lost. So alternative ways to make sure that that gets kept as it is and can get additional eyes on it for anyone that might want to work on it or continue adding and fixing and updating. Some of the some of the pull requests require a little bit of more knowledge and more expertise in some areas. So it may be tough, but there is a great base to work from in all of these. And Meg Whitestone or no, sorry, I can't remember Meg's last name right now. Meg McRoberts. Meg McRoberts, yeah, has done an excellent job and there's a bunch of pull requests that update a lot of the documentation that just have gotten stalled because they need some further additions, corrections, updates and stuff. So there's a lot of great stuff there that we can just take on and work from. So we do have a stalled label that has been applied to these pull requests as well. So for anything older, it's marked stalled. We have that, we're just waiting to do the next step of what do we do with that? Putting it installed is good for now, but ultimately we're gonna need to make sure that it's available for other people. And if it's a good first issue, we can do that. If we put it in the issue tracker that at least opens it up for other people to work on. There's a lot of ways to go about that. Something that we also talked about with Alex Brandes is that the Jenkins Core repository has a proposed for closed label. So that's used for pull requests they won't accept or they have an inactive submitter that are not responding or updating. So again, something similar we could use that we could implement and use that in Jenkins.io repository, no problem. And it would give us something else to at least signify and notice on the pull request page. Bruno, Mark, are there any other ideas or suggestions about how we could potentially preserve those a little and make them more visual? Actually, I think we take that as our plan and just agree that we think that's what we're gonna do. Okay, that works. The only problem I see with that is that if ever a submitter of a pull request removed the branch from his fork, we will lose the information nonetheless if I'm not mistaken. If you create a PR then you remove your branch, the information you wanted to incorporate into the main branch just disappears. I thought that it was retained in the pull request. I may be wrong. I thought it was. But nonetheless, because if I recall correctly, even if I believe it survives, even if they delete their fork. Okay, cool. But it's easy to check. Good idea that we may want to check it. Yeah, definitely. Thanks, Bruno. Appreciate that and thought of that. Next up, so end of life notifications in Jenkins Core. This is something that we had been discussing. The idea is that it can be delivered via the administrative monitor or administrative monitor. And right now it's designed as a general solution to communicate end of life dates. There are gonna be factors, attributes that we wanna account for and look at to use for when this message can be sent out, who it's gonna be sent out to, what that end of life version is, et cetera, et cetera. So as I mentioned, Mark's been getting more and more insight and feedback on this and various things that we can use as criteria. The most recent one is the start date for end of life messages, which essentially would just be when do we wanna start sending these out to people? And not right now, but in a specific, like a given timeframe, six months before the end of life, so that there is ample time to see that notification and actually act on it instead of having it be so sudden that if there's no time or too far away that it gets lost. And this also will allow us to end of life container images. So in not only just the platform systems versions that people are working on, but full container images as well so that we just clean things up, you keep things nice and streamlined and people are using the up-to-date versions of Jenkins and anything else that we're working with. And then finally, so the early end of CENTOS 7 for the Jenkins project has been discussed in the docs office hours for a little bit now. Mark's gonna submit a JP for that and we'll work from there to get the end of life straightened out on CENTOS 7. It's approaching sooner than later. It's no longer being supported by the developer and we do have alternate options available and even listed in the documentation such as AMA Linux 8 or 9, Rocky Linux, REL, Oracle Linux, and there are others. So there is still more to come on that but the work is being done and we're getting everything ready to go for that. So, okay, so that brings us to the end of our session. Did anyone have anything else to add, note, comment, share? All right, in that case, I'm gonna go ahead and stop the recording in just a moment. Recording will be available in 24 to 48 hours and thanks again as always for joining here today. Take care.


Felly, rydyn ni'n ddod i'r ddweud, ac rydyn ni i'n ddod i'r ddweud y teulu gyda'r teulu. Rydyn ni'n ddod i'n ddod i'r ddweud o'r ddweud yn holl ymlaen, felly, mae'r sefyllt o'r ddweud, ymlaen o'r ddweud o'r ddweud yn holl ymlaen, oherwydd o'r TV, rheidio, a gynnal o'r internet. Mae'r holl yn 200,000 o'r ddweud ar gwrs. reliable values. So a central concern for us is how can we design effective teaching, learning and assessment for education at massive scale. So in brief, some educational methods relief get worse when you try to scale them up. So personal tutoring, sports coaching is an example of that. It just doesn't work to do sports Sfertyn ychydig wrth hollach ac rhai gyfnodd aethau. Mae'r fan ddechrau ddechrau opeth genechi i gyd yn fwy, yn dweud ysgael. Er efallai, yn ei fanyddio, mae'n dweud i gael wedi ceisio i'r fan ffoddi. Maen nhw'n mynd ystod o'r gallu gweithgabeth. A hynny oedd y gallai'r teulu a'r bysau, mae'r fan ddechrau i hefyd yn dweud eraill o'r fan fwy, yn ystod o'r gweithgabeth. Ac rhaid diwethaf foster gweithgabeth rhaid? That is a central preoccupation for us. Can we design teaching and learning method that the more people who take part, the better they get? So there is something called Metcalf's law which was originally formulated for network systems. Which is that for some network systems the value of a product or services increases with the number of people using it. An example of that is a telephone system, If you've only got two telephones in the world, it's not terribly useful. As more and more telephones were invented and marketed, then the telephone system became more useful. When you had international subscriber dialling, it became even more useful. That's to the user. Obviously to the telephone operator, there are complexities, complexities of how to manage these many interacting people. But they're technical problems that can be solved. So in general, there are some network systems that become more valuable to users as more people are connected. But of course we're not just points in a telephone network. We want to enable people to do productive learning. And so to enable learning, networks need to support effective conversations for learning that are new, important, timely, usable, understandable, appropriate, and most of all trusted. We need to have trusted conversations for learning between people. And so that's what we're looking at now. How can you develop effective social networks for learning, bringing in some of the findings from other social network sites like Twitter and like Facebook? How can we harness the power of social networks to support effective learning? And most of you, I'm sure, know about FutureLearn. FutureLearn is a company that was formed by the Open University. It was launched in 2013 in October. It has 40 partners, 130 courses, over three quarters of a million registered learners and one and a half million course registrations. It enables people to learn on their mobile devices where and whenever they want to. But it was based on a specific approach to teaching and learning, which we're calling social learning as a shorthand. And that social learning is how can you harness the conversations of many tens of thousands of people so that it's not just a one-way channel of communication from lecturer to student, but the learners themselves can support each other through productive conversation and interaction. To give you an example, this is one of the courses from FutureLearn, the Start Writing Fiction course put on by the Open University. Over 25,000 learners took part in this course from 139 countries. Every piece of content in FutureLearn is linked to learner conversations. So, instead of sending learners off to separate forums, their conversations are always in context around the learning materials. And it works. This social network learning linked to the content really well. When we set it up, we really weren't sure whether people were going to converse around their learning materials. And we were initially pleasantly surprised and now pretty much astounded that people do engage in these productive conversations. Nearly half of the people who took part in the Start Writing Fiction course contributed to discussions. Over 7,000 contributions to one single discussion. And that was a discussion that was set up where learners were asked to produce their own very, very short story. And here's an example from that. It's one that I went on to the course and just picked one almost at random. It was a learner there who said, I got a bit carried away, but here's what I came up with. They were asked to write one paragraph with three pieces of fiction and one fact, and then one paragraph with three facts and one piece of fiction. And I won't read it all out to you, but it's quite a heart-wrenching one paragraph, very, very short story. And another learner responded at the bottom, I love that last piece you've written, Catherine, heart-breaking yet beautiful. These are the sorts of conversations that take place on a future-learn platform. Citizen science. So what I want to do next is say, how can we take this sort of conversational learning one step forward? And this is where I'm going to connect in with what Eileen Scanlon has said about how can you bring in the power of active learning and inquiry learning? I'm just going to show you a short video that will introduce it. Citizen science is about curiosity and inquiry, forming teams to carry out investigations, asking the right questions, getting up close to nature, going beyond the senses, collecting data, finding answers, sharing the results. The Inquirer Learning System and the Open Science Lab together form a powerful platform for open online science. We want to take the best of open university practical science and make it available to the next generation of scientists, not just to look and admire, but to get involved. You'll be able to design investigations, engage in inquiry learning and experience the thrill of finding things out. Citizen science makes scientists of us all. So we're developing something we're calling Citizen Inquiry that brings together Citizen Science and Inquiry Learning. Members of the public not just doing other people's science but initiating their own science investigations and using their own technology. So we've got an app. You can download it from Google Play called SENSIT. It unlocks all of the sensors on mobile phones. This is the first app to have done this. There's about 15 sensors on a modern smartphone, tilt, acceleration, pressure sensors, and we've unlocked them for this social learning and for Citizen Inquiry. So you can use, for example here, the orientation sensor. You can create projects using combinations of sensors and you can engage with other people, other people's projects. So you can either take part in projects that people have initiated or you can set up your own Citizen Inquiry project. Some examples of the ones that are already underway. How would you use a smartphone or tablet to measure the height of a tree or a building? Well, you can use a tilt sensor. Find out where the birds are scared by city noise. Create your own portable weather station. Find out which is the fastest lift in your country or learn about rocks, clouds, trees and birds or fashion in different countries. We put it all together on a Citizen Inquiry site called Inquiryt. Again, you can go to that site, inquiryt-it.org and you can see the missions that members of the public have set up there. I'm just going to show you quickly one of those missions. Identify clouds. So we've got a whole range of people ranging from pure amateurs who are just interested in pretty clouds up to climatologists and meteorologists. So one example of the latter is a picture there of somebody who posted up a set of lenticular clouds. It's a particular cloud formation and there are comments on that lenticular cloud formation. So we've got amateurs and professionals coming together not just doing other people's science but initiating their own scientific inquiries. Another example there from a colleague in Buenos Aires is creating a noise map using mobile phones around Buenos Aires, posting the data and then sharing it with other people. So these are some examples of the sorts of innovations in teaching, learning and assessment that we're looking at at the Open University, particularly ones that get better with scale. The more people that get involved, the better it gets. And to finish off, we produce an annual series of reports called Innovating Pedagogy which are about these innovations in teaching, learning and assessment not just from the Open University but around the world. And they've been very successful. We've had over 10,000 downloads of the last one and we're reaching that almost now from this year's of 2014 one. Massive open social learning, which I put at the top is only one of the many innovations that we've highlighted in this report. You can find it at open.ac.uk slash innovating. Thank you.